 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsElectronicsBasicsRepairDesignCADComponentsEquipmentElectrical Engineering ElectronicsKB.com Contact UsLink To UsSearch & Site Map |
Electronics Forum / Design / August 2008A chip too far? Where is your solution Mr Larkin?
A chip too far? Where is your solution Mr Larkin? http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 Blowing in the wind, all blowing in the wind. >A chip too far? Where is your solution Mr Larkin? > http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 > >Blowing in the wind, all blowing in the wind. 1. A new programming language, accompanied with a new way of teaching programming. 2. A new OS, which uses a nanokernel approach and wastes processors in the name of reliability. 3. Ultimately, a new multicore cpu architecture that exerts much more hardware control over the things that programmers tend to screw up. The current generations of languages, programmers, methods, and OSs are relics, and they don't scale. It will take a long time to fix things, because the current computer culture - academics, programmers, cpu makers, Microsoft - will fight for its survival. John >>A chip too far? Where is your solution Mr Larkin? >> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 18 lines] > >John No, I can only very partly agree. Starting at the end, it now seems survival is for those who solve this problem first, in the widest sense. I would expect MS and others to know this, they are investing into research into this. As a second point, 'maybe' just 'maybe' the multi core approach is the fundamentally wrong one. In an other thread FPGA's rising over DSP's diminish is mentions. Sure, with so many gates, and reconfigurable logic, some parts of sequential programs are better done in FPGA then smearing out over many cores, my personal experience with this is fast DES. As mentioned, in (3), I did mention this earlier in an other posting, it is very difficult to use a CPU for each thread, and, as the article on CNN says, it is very difficult to get 9 women to give birth to one child in 1 month. I had an old boss, he would ask, 'How many more men do you need to do this within 2 weeks (as opposed to 3 month). I had lengthy discussions about communication between workers being a factor that could slow things down (as bottleneck). Sure, the joke goes: How many Belgians does it take to screw in a light bulb?', and the answer is: 5, 1 to hold the bulb, and 4 to turn the ceiling. But something there says it all. Perhaps when we use FPGA as supplement to a sequential processor (where extra processors can be configured in hardware too), then we can gain speed. I fail to see an universal way to slice any sequential problem to a parallel one. But _if_ you do, you can become world famous, extremely rich, so I'd say: Call MS or IBM :-) So, blaming it all on 'programmers' is a bit silly (with all respect). the first programs were hardwired anyways, blame it on the hardware guys... The best way to optimise for speed, is to see where the system spends it time, and tackle that bottleneck, if must be put a FPGA there, not add yet an other core, with its communication issues. > So, blaming it all on 'programmers' is a bit silly (with all respect). > the first programs were hardwired anyways, blame it on the hardware guys... Anybody remember The Connection Machine? http://en.wikipedia.org/wiki/Connection_Machine ISTR the reason it never found any real applications is that nobody knew how to program it. Cheers! Rich >>>A chip too far? Where is your solution Mr Larkin? >>> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 57 lines] >and tackle that bottleneck, if must be put a FPGA there, not add yet an other core, >with its communication issues. RPU - Reconfigurable Processor Unit www.drccomputer.com Dynamic configuration of FPGA on an application basis. > >>A chip too far? Where is your solution Mr Larkin? > >> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 27 lines] > As a second point, 'maybe' just 'maybe' the multi core approach is the > fundamentally wrong one. The problem is that, fundamentally, it's the only one. > In an other thread FPGA's rising over DSP's diminish is mentions. > Sure, with so many gates, and reconfigurable logic, some > parts of sequential programs are better done in FPGA then smearing out > over many cores, my personal experience with this is fast DES. Do note that DES was designed to be done in hardware. In fact, if it's not implemented in hardware it's not DES. > As mentioned, in (3), I did mention this earlier in an other posting, > it is very difficult to use a CPU for each thread, and, as the article [quoted text clipped - 12 lines] > I fail to see an universal way to slice any sequential problem to a > parallel one. However, the world seldom has only one problem to work on at a time. > But _if_ you do, you can become world famous, extremely rich, so > I'd say: Call MS or IBM :-) What? And have them bury it along side the 100MPG carburetor? ;-) > So, blaming it all on 'programmers' is a bit silly (with all respect). > the first programs were hardwired anyways, blame it on the hardware guys... What is "it"? > The best way to optimise for speed, is to see where the system spends it time, > and tackle that bottleneck, if must be put a FPGA there, not add yet an other core, > with its communication issues. If it's that important, put it in custom logic. FPGAs can't compete here either. It's all a trade-off (it's called "engineering" ;).  SignatureKeith >> As a second point, 'maybe' just 'maybe' the multi core approach is the >> fundamentally wrong one. > >The problem is that, fundamentally, it's the only one. Nope, as I stated, _if_ you want more speed, look where the program spends its time. Then optimise that part, use hardware. These guys got it: http://www.drccomputer.com/ http://www.xtremedatainc.com/index.php http://www.intel.com/technology/platforms/quickassist/index.htm It is not just DES, sure DES designed so it could be easily done in hardware. Nearly any thing that uses DSPs to speed up signal processing can now be done (and perhaps faster) in FPGA. The issue is, what part of the software can be allocated to FPGA as resource. You must be aware, that most programs with multiple threads have very different load factors for the threads, some threads may just wake up occasionally, while others do the heavy work (eat CPU cycles). So adding cores for each thread makes no sense, as those cores would do next to nothing, adding one core to do all the low intensity threads even makes no sense, as such a low intensity thing can then just as well occasionally run on the main CPU. Mr Larking has some idea it would be safer to spread threads over all cores, but there is no proof of that. Safer then 100% reliable is not possible anyways (Like a good Linux system :-) ). I think the universities, big companies like Intel, IBM, Altera, Xilinx, and the above mentioned companies that already have solutions, should get together to make some open compiler / specification so it can be done automatically. You see that a 100x speedup for a big database using one FPGA based module in a spare CPU slot is a lot, it would take 100 cores extra to do that, if cores added linear to speed. So, throwing more cores at the problem is the wrong method, may seem easy if you are used to use cores for everything, but they have to let go of that idea. >>> As a second point, 'maybe' just 'maybe' the multi core approach is the >>> fundamentally wrong one. [quoted text clipped - 31 lines] >So, throwing more cores at the problem is the wrong method, may seem easy if you are used >to use cores for everything, but they have to let go of that idea. So write a letter to Intel and tell them that they're all wrong. http://www.watblog.com/2008/07/18/intel-tells-developers-to-be-ready-for-thousan d-core-processing-soon-to-ship-8-cores/ John >>>> As a second point, 'maybe' just 'maybe' the multi core approach is the >>>> fundamentally wrong one. [quoted text clipped - 37 lines] > >John Why, because they sue websites with the word 'inside' in it? Why in the world would I help Intel? Anyways they KNOW: http://download.intel.com/technology/quickassist/fsbfpga.pdf Note that on page 4 of the pdf it says: Targeted for ... oil and gas ... If you actually read the postings and followed the above links, you would have found this. You mentioned Russian oil as one of your customers. I'd be alert, the competition also wants to sell. It is easy to say: 'Everybody makes crap, our products are perfect.' That is sales talk (and bad at that, as it upsets every other company). But one of these days complexity is needed, speed, at least for some segments of that market, and if you want to compete you better have the real stuff. Computing has moved a a lot since TI45 calculators and pencil drawn diagrams, and electric pencil sharpers, 68000 CPU, remember Motorola Maxboard? >>>>> As a second point, 'maybe' just 'maybe' the multi core approach is the >>>>> fundamentally wrong one. [quoted text clipped - 55 lines] >Computing has moved a a lot since TI45 calculators and pencil drawn diagrams, >and electric pencil sharpers, 68000 CPU, remember Motorola Maxboard? Do I have to give all the money back? One of the reasons we don't need massive computing power in our embedded products is that stuff is progressively moving into FPGAs, with the uP doing relatively slow setup, housekeeping, and user interface, as the FPGA does ever-more complex stuff at increasing speeds, all in parallel at hundreds of MHz. In one recent case, we moved a calibration routine, a multiply, a couple of saturating adds, and a long signed divide, multiple ranges times 16 channels, from uP code into FPGA hardware. That radically simplified my code... I only load the cal coefficients from eeprom into the fpga at startup time, and then just poke the normalized data as I get it. Another small example of parallel hardware and zillions of transistors simplifying what would have been a complex procedural software approach. Get used to it. We'll move onto one of the Coldfire chips some day, when we come across a problem that needs more horsepower, but doesn't justify just dropping a mini-ITX motherboard into the box. For $300 or so, with all those goodies like gigabit ethernet and flash and ports and Linux and stuff, it's hard to beat an x86 board for box-level products. John > In one recent case, we moved a calibration routine, a multiply, a > couple of saturating adds, and a long signed divide, multiple ranges > times 16 channels, from uP code into FPGA hardware. That radically > simplified my code... Yeah, but I bet the guy who implemented the FPGA version of that algorithm spent more time doing it than you did with the assembly version -- hardware description language synthesis tools are nowhere as good at creating fast, efficient implementations as software compilers are. Indeed, with FPGAs we're still at the point where most people use the "library" approach: Xilinx provides, e.g., a FIR filter "block," a divide "block," etc., and you just instantiate them in your HDL and wire'em up. Works fine, but not as clean as software development. Much faster execution though, of course. > For $300 or so, with all > those goodies like gigabit ethernet and flash and ports and Linux and > stuff, it's hard to beat an x86 board for box-level products. I agree with you there -- designing your own SBC with a contemporary 32-bit CPU, SDRAM, flash ROM, Ethernet, etc. is insane (unless of course that's what your company's end product is going to be). ---Joel >> In one recent case, we moved a calibration routine, a multiply, a >> couple of saturating adds, and a long signed divide, multiple ranges [quoted text clipped - 9 lines] >instantiate them in your HDL and wire'em up. Works fine, but not as clean as >software development. He did it in about a half hour, probably close to the time I spent on the firmware version. >Much faster execution though, of course. Yup, it cut our channel update time by some goodly factor, 3:1 maybe. >> For $300 or so, with all >> those goodies like gigabit ethernet and flash and ports and Linux and [quoted text clipped - 5 lines] > >---Joel John > He did it in about a half hour, probably close to the time I spent on > the firmware version. So I take it he used a library module for the divide routine then? Writing "x = a / b" in VHDL or Verilog often isn't even synthesizable, and when it is, I'd be a little leery of the efficiency of the implementation. (Although I'm told that "x = a * b" usually generates efficient multipliers these days...) > Yup, it cut our channel update time by some goodly factor, 3:1 maybe. Cool. ---Joel > On Fri, 22 Aug 2008 14:50:49 GMT, Jan Panteltje ... >>It is easy to say: 'Everybody makes crap, our products are perfect.' >>That is sales talk (and bad at that, as it upsets every other company). [quoted text clipped - 4 lines] > > Do I have to give all the money back? Only if you get caught. >:-> Good Luck! Rich > >> As a second point, 'maybe' just 'maybe' the multi core approach is the > >> fundamentally wrong one. [quoted text clipped - 3 lines] > Nope, as I stated, _if_ you want more speed, look where the program spends its time. > Then optimise that part, use hardware. That's hardly a generalized solution (as in "general purpose computer"). > These guys got it: > http://www.drccomputer.com/ [quoted text clipped - 4 lines] > Nearly any thing that uses DSPs to speed up signal processing can now > be done (and perhaps faster) in FPGA. DES isn't in the same class as most other problems. Pipelining becomes a problem. Sure, FPGAs are generally faster than sequential software but code development is a *lot* more expensive. > The issue is, what part of the software can be allocated to FPGA as resource. There are a *lot* more issues than that. > You must be aware, that most programs with multiple threads have very different > load factors for the threads, some threads may just wake up occasionally, [quoted text clipped - 9 lines] > companies that already have solutions, should get together to make some open compiler / specification > so it can be done automatically. Just tap your shoes together three times... > You see that a 100x speedup for a big database using one FPGA based module in a spare > CPU slot is a lot, it would take 100 cores extra to do that, if cores added linear to speed. > So, throwing more cores at the problem is the wrong method, may seem easy if you are used > to use cores for everything, but they have to let go of that idea. If your world is one problem, then use fully custom hardware. It'll beat an FPGA all to hell. Cost is an important engineering parameter. SignatureKeith >>>> As a second point, 'maybe' just 'maybe' the multi core approach is the >>>> fundamentally wrong one. >>> The problem is that, fundamentally, it's the only one. >> Nope, as I stated, _if_ you want more speed, look where the program spends its time. >> Then optimise that part, use hardware. > > That's hardly a generalized solution (as in "general purpose > computer"). It is one possible soution for extremely compute bound problems though. A more generally applicable one is the class of profile directed optimisers that try much harder to optimise the hot spots where the program spends more than 80% of its time (and so offer the best return on investment). Profiling feedback can make an important difference to how well a program can be optimised for a given archicture. A quick intro to the basic idea in the context of Alpha emulation of x86 code with a post execution binary converter applied to hotspots. http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/mi/&toc=co mp/mags/mi/1998/02/m2toc.xml&DOI=10.1109/40.671403 (abstract only) Regards, Martin Brown ** Posted from http://www.teranews.com ** In article <3b67e$48b3c266$12107@news.teranews.com>, |||newspam|||@nezumi.demon.co.uk says... > >> [quoted text clipped - 9 lines] > > It is one possible soution for extremely compute bound problems though. So is fully custom hardware. Neither are a good general solution. > A more generally applicable one is the class of profile directed > optimisers that try much harder to optimise the hot spots where the > program spends more than 80% of its time (and so offer the best return > on investment). Profiling feedback can make an important difference to > how well a program can be optimised for a given archicture. How does a profiler determine how *well* a program can be optimized? It certainly can determine where to attack the problem, and perhaps how big the challenge is, but quantitatively how well? > A quick intro to the basic idea in the context of Alpha emulation of x86 > code with a post execution binary converter applied to hotspots. > > http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/mi/&toc=co mp/mags/mi/1998/02/m2toc.xml&DOI=10.1109/40.671403 > (abstract only) (no internet connectivity SignatureKeith > In article <3b67e$48b3c266$12107@news.teranews.com>, > |||newspam|||@nezumi.demon.co.uk says... [quoted text clipped - 19 lines] > It certainly can determine where to attack the problem, and perhaps > how big the challenge is, but quantitatively how well? Quantitatively on realistic compute bound performance benchmarks like SPECint95 they are about 15-20% better on average than the best static optimisers. Probably slightly better now for heavy numeric code, but the first open access review paper I found is from 2000. http://www.eecs.harvard.edu/hube/publications/dynamo00.pdf It is a very nice introductory paper on the subject. The compiler can try all the tricks of loop invariance, inlining and unrolling loops that it knows on a small section hotspot to find by trial and error what works to make things go faster and what doesn't. There are known heuristics most people would use but the compiler can try them out in all combinations and then make the best choice. Programmers worry about aggressive optimisers breaking perfectly valid code. But these days a human would struggle to satisfy the no stall rules and maintain readability for a pentium processor whereas a decent compiler can shuffle instructions around to make best use of the pipeline. FFTW does something similar at runtime to encode the wisdom of the order in which to apply the small radix codelets for maximum performance. After the wisdom has learnt how to do it same length transforms are much faster running on that machine. >> A quick intro to the basic idea in the context of Alpha emulation of x86 >> code with a post execution binary converter applied to hotspots. [quoted text clipped - 3 lines] > > (no internet connectivity Those keywords ought to get you something comparable. Regards, Martin Brown ** Posted from http://www.teranews.com ** >> A chip too far? Where is your solution Mr Larkin? >> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 3 lines] > 1. A new programming language, accompanied with a new way of teaching > programming. That might help a bit. But there are a lot of very important legacy applications already out there. Like it or not we are tied into the existing applications codebase. > 2. A new OS, which uses a nanokernel approach and wastes processors in > the name of reliability. Can't fault the idea of keeping the Ring0 protected kernel as small as possible, or giving users the least privileges needed to do their job. But wasting performance for reliablity though is never going to fly - not least because most times it would not have the desired effect. Hardware enforced memory protection for threads on a timesliced CPU can be made every bit as reliable as giving each one a physical CPU just a SMOP. > 3. Ultimately, a new multicore cpu architecture that exerts much more > hardware control over the things that programmers tend to screw up. You mean like enforcing bounds checking on array and pointer access? I am all in favour of that, current CPUs have some of the right instructions but most production code has these safety nets optimised out in final build. Performance, whizzy graphics and even mythical faster benchmark figures sell kit - sadly reliablity doesn't(*). (*) except for certain high availability mission or saftey critical kit. > The current generations of languages, programmers, methods, and OSs > are relics, and they don't scale. If you don't remember your history you are doomed to repeat the same mistakes. Do you not remember the Transputer and its lovely little parallel processing language Occam. Scaled really well but they went bust - probably because they were manufacturing in the UK. http://en.wikipedia.org/wiki/Transputer I might even be tempted to agree with you that the time is now right for someone to try this route again. I predict lots of fun and games for desktops with Vista and N>4 x86 compatible CPU cores. > It will take a long time to fix things, because the current computer > culture - academics, programmers, cpu makers, Microsoft - will fight > for its survival. Academics are a lot more sanguine about things than you seem to think. Most that I know believe the market gets what the market deserves. If people will buy vacuous buggy software with a cute interface that crashes when the wind changes direction then manufacturers will oblige. Regards, Martin Brown ** Posted from http://www.teranews.com ** >>> A chip too far? Where is your solution Mr Larkin? >>> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 23 lines] > >You mean like enforcing bounds checking on array and pointer access? Pointers have to be the first thing to go. And of course array bounds should be checked, but all that can do is crash a program, which was going to crash sooner or later anyhow. We are programming antique hardware in antique languages. >> It will take a long time to fix things, because the current computer >> culture - academics, programmers, cpu makers, Microsoft - will fight >> for its survival. > >Academics are a lot more sanguine about things than you seem to think. The ideal programming language would be wordy, plodding, not a bit exciting - sort of like Cobol - and no fun for research or for coding. That's the point: we have to make programming not fun if we want it to be reliable. Modern programming attracts the wrong kind of people to teach and do reliable programming. >Most that I know believe the market gets what the market deserves. If >people will buy vacuous buggy software with a cute interface that >crashes when the wind changes direction then manufacturers will oblige. When later versions of programs are slower and buggier, "the market" will oblige by not upgrading. We have seen this here a few times - a new rev is worse than the current one - so we drop support and stick with the one that works. Or we go to a free equivalent, like PDF utilities or LT Spice, and dump the bloatware. John [snip] >When later versions of programs are slower and buggier, "the market" >will oblige by not upgrading. We have seen this here a few times - a [quoted text clipped - 3 lines] > >John I think it's a fundamental problem of the U.S. (and perhaps the rest of the world as well). We've allowed ourselves to be hung up on _growth_, if earnings/whatever don't grow every quarter we think we're not succeeding... it's not satisfactory to have a steady profit... so we sink/sell companies willy-nilly. Same with software... if there's not a periodic "upgrade" it must be a failure. I've taken to asking for detailed reports on software improvements before I spend my "maintenance" money. Not surprisingly, I've not recently spent any money ;-) ...Jim Thompson | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | Obama, without aid of teleprompter, "Uh...Uh...Uh...Uh...Uh..." On Aug 19, 11:41 am, Jim Thompson <To-Email-Use-The-Envelope-I...@My- Web-Site.com> wrote: > [snip] > [quoted text clipped - 11 lines] > not succeeding... it's not satisfactory to have a steady profit... so > we sink/sell companies willy-nilly. That's Bill Gate's major innovation--his solution to the question "How can you make loads of money off a product that never breaks, and never wears out?" His answer is a combination of making sure the thing you buy is defective, and or deficient, or of making it obsolete, and parcelling out improvements (and even fixes) as slowly as possible. Hence changing Word and Excel's formats, changing the OS to break old applications, shipping bugs, security issues, etc. It just hit me yesterday--I've oft noted the harm he's done selling lousy software, but I just realized...he breaks our tools. My superb DOS file compare, search routine, editor, directory utility, parallel port-operated interfaces, truly nifty ISA A/D board... broken. The advance of civilization has been one of building tool upon tool, hand tools ==> machines ==> machine tools ==> better machines ==> better tools. Same for software. And he breaks ours. Thanks Bill. James Arthur >On Aug 19, 11:41 am, Jim Thompson <To-Email-Use-The-Envelope-I...@My- >Web-Site.com> wrote: [quoted text clipped - 42 lines] > >James Arthur http://www.theregister.co.uk/2008/08/19/windows_xp_vista_7/ John > >> [snip] > [quoted text clipped - 3 lines] > >> >with the one that works. Or we go to a free equivalent, like PDF > >> >utilities or LT Spice, and dump the bloatware. <SNIP: The advance of civilization has been built tool upon tool...and Bill Gates breaks ours.> > >Thanks Bill. > [quoted text clipped - 3 lines] > > John Here's what Charles Wenzel did: (a beautiful story, but top-posted. Start at bottom.) http://www.techlib.com/linux_rules.htm Cheers, James Arthur >> >> [snip] >> [quoted text clipped - 18 lines] >Start at bottom.) >http://www.techlib.com/linux_rules.htm No, 'I never touched the command line' is WRONG. Recently somebody at IBM, in command of the Linux stuff, stated: 'Do not immitate MS windows'. A lot of GUI stuff is just screening you from the simple basic computer interface that the command line provides. For example, what will be faster: Typing firefox in an xterm, or finding it in a file browser, and then clicking on it. OK, maybe you have a Firefox icon on your desktop. But you know, there are thousands of commands, and you cannot possibly have them all as icon on the desktop. So if I type route or uptime or ls -rtl or basically _ANY_ Unix command, like for example invoking a text editor joe mytext.txt Then I am thousands of times faster then somebody searching trough file menus. Maybe the reason Suse is in bed with MS (and now recently even more egain), is that both use bloat. Suse uses KDE, KDE is based on Trolltech's Qt. Qt-4 is an example of bloat. The command line provides an English speaking interface to your computer, can easily be coupled to speech recognition too. MS wants to make people into dumb mouse clickers, preventing them to understand the computer, binding them to their weird interface. > MS wants to make people into dumb mouse clickers, preventing them to > understand the computer, binding them to their weird interface. That's their market. The command line is handy sometimes. Typing is faster than keying a 1- baud serial interface with your finger; higher bandwidth, and more precise. Cheers, James Arthur >> >> [snip] >> [quoted text clipped - 21 lines] >Cheers, >James Arthur Autodesk did the same to us, sicced a lawyer on us demaning that we prove we weren't abusing their license rules. They sure cured us of ever buying Autocad products again. John >>> >> [snip] >>> [quoted text clipped - 27 lines] > >John Besides, Bentley MicroStation is better, more flexible, easier to use, more reasonable licensing, and best of all, less expensive. >>>> A chip too far? Where is your solution Mr Larkin? >>>> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 21 lines] > should be checked, but all that can do is crash a program, which was > going to crash sooner or later anyhow. Pointers are OK provided you can only trash your own memory space. Anything else and you should get squashed flat. > We are programming antique hardware in antique languages. Speak for yourself. I program in the language that best fits the problem (or is dictated by the clients requirements). Sometimes both. The fastest way to develop really tricky algorithms is in a language where human errors and typos are mostly caught at compile time. The final version is then translated back into C (which is mostly what people seem to want). ISTR NAGLIB used this approach a very long time ago (when FORTRAN was the main language of choice for scientific computing). I wish that a more robust language had won the language wars, but it is too late now to cry over spilt milk. >>> It will take a long time to fix things, because the current computer >>> culture - academics, programmers, cpu makers, Microsoft - will fight [quoted text clipped - 3 lines] > The ideal programming language would be wordy, plodding, not a bit > exciting - sort of like Cobol - and no fun for research or for coding. In the sense that the compiler protects the average user from themselves I have to agree with you. But you actually do need really good visualisation skills and a logical mathematical mind to produce reliable code. Good intentions are insufficient. > That's the point: we have to make programming not fun if we want it to > be reliable. Modern programming attracts the wrong kind of people to > teach and do reliable programming. Even that isn't clear. I do have some sympathy for your argument that hardware engineers in general tend to be better at thinking through the details, unit testing and planning. But nobody wants to pay for truly reliable software when the law of diminishing returns sets in. You might want to take a look at Donald Knuths literate programming model used for TeX. It has one of the lowest bug rates of any program ever written. And hardware implementation isn't really as robust as you like to pretend with your rose tinted glasses on. Various CPUs have had nasty bugs the worst one costing Intel a cool $0.5B (depsite being largely irrelevant for most users). I had a specimen dodgy PII - it even made a tiny difference for one regression test. So far no-one has produced a full CPU with a formal proof of correctness. Components have been stratin with the Cyrix x87 copro. ISTR some bad liability lawsuits resulted from the Viper CPU debacle. http://www.cs.berkeley.edu/~gporter/pubs/roleofproof.html >> Most that I know believe the market gets what the market deserves. If >> people will buy vacuous buggy software with a cute interface that >> crashes when the wind changes direction then manufacturers will oblige. > > When later versions of programs are slower and buggier, "the market" > will oblige by not upgrading. We have seen this here a few times - a Not enough to change the market dynamics - at least so far. > new rev is worse than the current one - so we drop support and stick > with the one that works. Or we go to a free equivalent, like PDF > utilities or LT Spice, and dump the bloatware. XL2007 is a case in point. Slower, unreliable and in places downright flakey. I would not even recommend it to my worst enemy, but some of my clients insist on having the latest and greatest despite being given clear advice to avoid. XL2003 is a local optimum, as was NT3.51 - even a chaotic process can sometimes produce real gems... Intel at least has had the good sense not to deploy Vista. YMMV I notice that you quietly editted out all references to the ill fated Transputer hardware and its naturally parallel Occam language. That was a serious early attempt to adopt your world model. It failed big time. Regards, Martin Brown ** Posted from http://www.teranews.com ** >>>>> A chip too far? Where is your solution Mr Larkin? >>>>> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 37 lines] >I wish that a more robust language had won the language wars, but it is >too late now to cry over spilt milk. So, a hundred years from now, everybody will still be programming in C++? Writing billion-line programs with millions of bugs? Something to look forward to. John >>>>>> A chip too far? Where is your solution Mr Larkin? >>>>>> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 37 lines] > So, a hundred years from now, everybody will still be programming in > C++? Writing billion-line programs with millions of bugs? I didn't say that at all. Hand written code has a worryingly high defect rate of about 0.2% (average) and as high as 5% worst case (IBM OS/360 study). So either you have to make every line do more by improving the languages to match specific application domains or weed out the human errors sooner by more sophisticated static code analysis. Almost every language from the birth of computing with a significant codebase is still going strong more than half a century later. The languages have evolved a bit and standards committees have haggled over the small print but they still exist. And they are still used. Cobol, Fortran, Algol, Basic, Lisp all have their roots in the late 1950's. I fully expect new kids on the block like Java and SQL and the various web markup languages to last at least a similar length of time. > Something to look forward to. If I had to bet how software engineering will evolve in the future then I would say that formal specifications will become more common for mission critical work. Z and VDM that we have now are effective, but very few people can read or work with them and manipulate proofs. Tools to support them and automatically convert the formal spec to a users view of how the interface will look and from that a conversion to functional code. Every path also has to handle changes and allow proof of correctness to be applied back to the specification. There are research projects trying to do this. It is distinctly non-trivial. And yet again you quietly snip away the embarrassing failure of the Transputer and Occam which followed your proposed massively parallel hardware route though expensively and somewhat ahead of its time. Regards, Martin Brown ** Posted from http://www.teranews.com ** >>>>>>> A chip too far? Where is your solution Mr Larkin? >>>>>>> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm ?postversion=2008081405 [quoted text clipped - 70 lines] >Transputer and Occam which followed your proposed massively parallel >hardware route though expensively and somewhat ahead of its time. I have not proposed a "massively parallel hardware route". I have observed that most CPU makers are going multicore, and that hundreds of cores, and maybe 1000 threads, will be available soon. And I have speculated on how that might affect OS design and programming. What's remarkable to me is how entrenched the current bloated and broken programming models are in the minds of programmers. Virtually everyone has responded to my speculations by telling me how good things are now, and how things will not change. So much for "design." As far as failed architectures go, lots of good stuff didn't make it. 68K is mostly gone. PPC ditto, as far as mainstream apps go. VAX and Alpha were wonderful. Modern structured languages used to be the rage. All have been blown away by Intel and Microsoft, x86 and Windows and C, the worst of the litter. John >All have been blown away by Intel and Microsoft, x86 and Windows and >C, the worst of the litter. Not to be so in envy, You can learn C too, it is a beautiful language: // test.c #include <stdlib.h> #include <stdio.h> int main(int argc, char **argv) { #define SMART 10 #define c_programmer SMART int he; for(he = 0; he <= SMART; he++) { if(he == c_programmer) { fprintf(stderr, "\ For he's a jolly good fellow, for he's a jolly good fellow\n\ For he's a jolly good fellow, which nobody can deny\n\ Which nobody can deny, which nobody can deny\n\ For he's a jolly good fellow, which nobody can deny\n"); } } exit(1); } /* end function main */ gcc -o test test.c grml: ~ # ./test For he's a jolly good fellow, for he's a jolly good fellow For he's a jolly good fellow, which nobody can deny Which nobody can deny, which nobody can deny For he's a jolly good fellow, which nobody can deny grml: ~ # Start reading Kernigan & Ritchie 'The C programming language'. http://www.amazon.com/C-Programming-Language-2nd-Ed/dp/0131103709 It is a bit old, but they invented it... In fact C is a step upwards the ladder from your asm. It has many of the features that asm alows, making C especially suited for writing drivers. The pointers are absolutely great for writing high speed code, with some self dicipline you won't make many mistakes with those. Always check in a function for null pointers, and do a graceull exit. I mean like this: #include <stdlib.h> #include <stdio.h> int debug_mode = 1; #define ERROR 0 #define SUCCESS 1 #define SUCKS 1 #define OK 0 char *text; int lines; int my_function(char *text, int *lines) { if(debug_mode) { fprintf(stderr, "my_program: my_function(): text=%s lines=%p\n", text, lines); } if(! text) return ERROR; if(! lines) return ERROR; // count text lines return SUCCESS; } int main(int argc, char **argv) { #define SMART 10 #define c_programmer SMART int he; if(! my_function(text, &lines) ) { fprintf(stderr, "Coding error.\n"); exit(SUCKS); } exit(OK); } /* end function main */ grml: ~ # gcc -o test test.c grml: ~ # ./test my_program: my_function(): text=(null) lines=0x8049820 Coding error. grml: ~ # LOL >>All have been blown away by Intel and Microsoft, x86 and Windows and >>C, the worst of the litter. [quoted text clipped - 41 lines] > >In fact C is a step upwards the ladder from your asm. No. My code gets done fast, runs fast, takes little resourses, is exaustively documented, is very easy to maintain and extend, is bug-free, and I formally release the code and the entire tool chain together. I suppose I could do that in C, too, but C is just too ugly. >It has many of the features that asm alows, making C especially suited for writing >drivers. >The pointers are absolutely great for writing high speed code, Writing should be done slowly and carefully. Most C coding is typed quickly and then dominated by bug finding and fixing. Runtime speed is rarely a big deal on multi-GHz processors. >with some self dicipline you won't make many mistakes with those. Tell Microsoft. >Always check in a function for null pointers, and do a graceull exit. There are no graceful exits in embedded systems. Exit == broken. >I mean like this: > [quoted text clipped - 50 lines] >LOL > C is crap, and the vast majority of C programs are crap. Your program has not a single comment, no indication of purpose, version, usage, authorship, limitations, or context. It looks like monkeys pounding on typewriters, and is literally "code" in the sense that it would have to be decoded character-by-character for anyone (including yourself, a few months from now) to understand what it does. If it were non-trivial, or important, all this would be much worse. .TITLE "28E346 REV A : T344/T346-1 WAVEFORM GENERATOR" .CPU "68332.TBL" ; ASSEMBLE FOR THE MC68332 CPU .HEX "MOT16" ; GENERATE 'S28' HEX FILE .SBTTL . **** T344/T346 EMBEDDED WAVEFORM GENERATORS **** .SBTTL . .SBTTL . BY JOHN LARKIN HIGHLAND TECHNOLOGY, INC .SBTTL . .SBTTL . August 8, 2008 .SBTTL . .SBTTL . COPYRIGHT HIGHLAND TECHNOLOGY, INC .SBTTL . .SBTTL . CAUTION: A6 IS RESERVED FOR XCOM, THE COMMAND PARSER .SBTTL . ; HARDWARE ASSEMBLY PCB 28A346 REV A TOP ASSY T346A ; CPU TYPE MC68LK332ACPV16 (TPU MASK SET 'A') ; CPU CLOCK EXTAL, 20 MHZ, OVERCLOCKED ; RAM 2K BYTES, CPU INTERNAL ; ROM TYPE 27C4001 4M-BIT (512K BYTES)) ; FPGA XC3S1500 PROGRAMMED 28C346B.RBT ; EEPROM NM93C86A 16 KBITS .SBTTL PROGRAM ID AND VERSION CODE = 28346 ; PROGRAM ID, FOR HARDWARE REV A REV = "A" ; AND CODE VERSION CTCODE = 28344 ; CAL TABLE ID CODE, T344 COMPATIBLE! DCCODE = 28346 ; CONFIGURATION VALID CODE ; THIS CODE IS USED ON BOTH THE T344 AND T346 PRODUCTS. ; CAL TABLE ENTRY C_OPT CUSTOMIZES THE VERSION. ; SERIAL OUTPUT CHARACTER "~" BECOMES "4" OR "6" ; HELP TEXT, SILLY, ROM CHECKSUM, AND THE FPGA CONFIG CAN BE PAST THE ; 32K BOUNDARY, SO NEED LONG ADDRESSING. ALL ELSE IS OK IN WORD MODE. ; REV A JULY 2008 FOR T344A AND T346A ; FPGA IS 28C346B ; .SBTTL BUILD AND MAINTENANCE PROCEDURES ; KEY PROJECT FILES AND PROGRAMS INCLUDE... ; ; 28E346x.MAC uP FIRMWARE SOURCE CODE, REX x ; 28C346x.RBT XILINX FPGA CONFIGURATION FILE ; ; GO.BAT BATCH FILE TO ASSEMBLE AND BUILD EVERYTHING ; ; PREP32.EXE SOURCE FILE PREPROCESSOR ; C32C.EXE CROSS ASSEMBLER (UNIVERSAL CROSS ASSEMBLERS INC) ; 68332.TBL OPCODE DEFINITIONS FOR C32C ; POST32.EXE LISTING FILE POSTPROCESSOR ; BRICK.EXE ROM IMAGE BUILDER ; ICD32.EXE BACKGROUND DEBUG PROGRAM ; ; 28E346x.ROM BURNABLE PRODUCTION ROM FILE ; (INCLUDES uP CODE AND XILINX CONFIG TABLE) ; ; TO PROCESS THE SOURCE FILES INTO A PRODUCTION ROM, ; JUST SAY... GO ; ; THIS WILL, IN SEQUENCE, INVOKE... ; ; PREP32 SOURCE PREFORMATTER MAKES 28E346x.ASM ; C32C UCA CROSS ASSEMBLER MAKES 28E346x.HEX, .LUG ; POST32 LISTING FORMATTER MAKES 28E346x.LST ; BRICK ROM FILE BUILDER MAKES 28E346x.ROM ; ; ; ALL FILES ARE RELEASED TO M:\LIB\SOFTWARE\28346\28E346x. IF ANY ; CHANGES ARE MADE WHICH AFFECT THE FIRMWARE EPROM IN ANY WAY ; (INCLUDING CHANGES TO THE uP CODE OR TO THE XILINX CHIP), THE ; REVISION LETTER OF THIS CODE MUST BE ROLLED AND A NEW VERSION ; RELEASED INTO A NEW LIBRARY SUBDIRECTORY. .SBTTL GENERAL DEFINITIONS etc and somewhat later on,... .SBTTL MAIN PROGRAM LOOP ; USUAL LOOP TIME IS BALLPARK 25 USEC. MAIN: MOVEA.L # STACK, SP ; RELOAD OUR STACK POINTER! MOVE.W # 2000h, SR ; RUN IN SUPER MODE, PRIORITY 0 ; CHANGE TO 2700 TO BLOCK ALL INTERRUPTS ; 2400 TO ALLOW QSPI, BLOCK TPU CLR.W QUIET.W ; MAKE SURE SERIAL OUTPUT IS ENABLED MOVE.W # 0303h, GREEN.W ; DO HEARTBEAT BLINK, AT 1 HZ BASS: ADDQ.W # 1, SLOPPY.W ; ABOUT EVERY 1.5 SECS, BCS.S PUPPY ; CHECK THE POWER BVC.S MERLIN ; AND DITTO JSR AZERO.W ; RE-ZERO THE ADC BRA.S SCAR ; PUPPY: JSR POWER.W ; CHECK THE POWER SUPPLY BRA.S SCAR ; (TAKES ABOUT 600 USEC) ; RECOMPUTE THE ERROR FLAGS WORD MERLIN: CLR.L D4 ; ZAP FLAGS-TO-BE CMPI.W # CTCODE, CALTBL.W ; IS CAL TABLE LEGIT? BEQ.S MERGE ; YES, SKIP ORI.W # CTERR, D4 ; NO, SET ERROR FLAG MERGE: OR.W BSFLAG.W, D4 ; INCLUDE BIST ERRORS OR.W AZFLAG.W, D4 ; AND ADC ZERO ERROR OR.W PSFLAG.W, D4 ; AND +12 ERROR OR.W CFFLAG.W, D4 ; AND CONFIG RECALL ERROR OR.W FPFLAG.W, D4 ; AND FPGA ERROR THING MOVE.W D4, FLAGS.W ; STASH SYSTEM ERROR FLAGS MOVE.W D4, RED.W ; AND USE AS RED BLINK PATTERN! ; CHECK FOR SERIAL COMMANDS IN THE RECEIVE BUFFER SCAR: TST.W RXDONE.W ; CHECK FOR <CR> FLAG BEQ.S BASS ; NO CR, DO FAST LOOP ; IF THE FLAG SAYS "DONE", WE HAVE A COMMAND IN THE SERIAL INPUT BUFFER. MOVEA.W # RXBUF, A6 ; AIM AT COMMAND TEXT IN BUFFER BSET.B # 0, CSPDR.W ; RAISE TP10 ============= JSR XCOM.W ; AND PARSE:EXECUTE COMMAND LINE BCLR.B # 0, CSPDR.W ; DUMP TP10 ============= MOVE.L # RXX, RXDONE.W ; SNEAKY: ZAP DONE FLAG ; AND LOAD BUFFER POINTER, MOST ATOMIC. BRA.S MAIN ; IT'S PRUDENT TO DO THE CLEANUPS NOW. .SBTTL . The .TITLE and .SBTTL directives build entries in the table of contents, which appears first in the assembly listing. The listing itself is nicely formatted and paged. All this takes *less total time* than the typical C hack. See the difference? John >>In fact C is a step upwards the ladder from your asm. > [quoted text clipped - 14 lines] > >Tell Microsoft. They used C++, we all know Stroussup did not know how to program ;-) >>Always check in a function for null pointers, and do a graceull exit. >There are no graceful exits in embedded systems. Exit == broken. Well,, the whole world is not embedded, and gracful exits _do_ exists in embedded systems, it should at least let the arbitration logic know it failed..., or tell the DVD player user to get a new version for the flash, perhaps swicth power, do some housekeeping, must be, witch to a backup, etc. >>I mean like this: >> [quoted text clipped - 52 lines] > >C is crap, and the vast majority of C programs are crap. Well, you seem to want some language war here, as you cannot write C, obviously your judgement is well, let's say.. incomplete, or not qualified. >Your program has not a single comment, no indication of purpose, >version, usage, authorship, limitations, or context. Maybe you should download one of the many programs I released, it is all very methodical, and all info is there. Largely the code is self-documenting, something you can do in C, but need a whole lot of cryptic comments for in ASM. >It looks like >monkeys pounding on typewriters, and is literally "code" in the sense >that it would have to be decoded character-by-character for anyone >(including yourself, a few months from now) to understand what it >does. If it were non-trivial, or important, all this would be much >worse. Bull, I maintain programs that are more then 10 years old, that carry _hardly_ any comments, as C is so self explaning (if done right). The whole problem is that you do not write in C, so you cannot read the source, it seems Greek to you. So learn it first. > .TITLE "28E346 REV A : T344/T346-1 WAVEFORM GENERATOR" > > .CPU "68332.TBL" ; ASSEMBLE FOR THE MC68332 CPU > .HEX "MOT16" ; GENERATE 'S28' HEX FILE > ; 2400 TO ALLOW QSPI, BLOCK TPU > CLR.W QUIET.W ; MAKE SURE SERIAL OUTPUT IS ENABLED > MOVE.W # 0303h, GREEN.W ; DO HEARTBEAT BLINK, AT 1 HZ >The .TITLE and .SBTTL directives build entries in the table of >contents, which appears first in the assembly listing. The listing >itself is nicely formatted and paged. All this takes *less total time* >than the typical C hack. No idea, present us with your C hack, so we can compare. >See the difference? Yes, C is much easier to read, easier to port, easier to compile, more universal (68??? CPU?) I still have an 68008 in the box. Never used. Been there for, lemme see, 20 years? >John You keep bashing C, well, you maye be in big trouble when they stop making your processors... You will be unable to write anything big, mmm let's see, how about a video processor, in asm. I will bury the language war axe here, I did refer you to Kernigan and Ritchie, all I can do,. Those who do not want to learn will stay as they are. In the meantime, look at this (as to subject related) http://www.xtremedatainc.com/index.php 100x speed, no multi cores needed. >>>In fact C is a step upwards the ladder from your asm. >> [quoted text clipped - 85 lines] >Well, you seem to want some language war here, as you cannot write C, >obviously your judgement is well, let's say.. incomplete, or not qualified. I've done a little C. It's choice, not inability, that makes me dislike it. Face it, most software these days is buggy and bloated. The last three major pieces of test equipmant we bought have numerous firmware bugs, and the vendor's software discipline is clearly chaotic. Keithley. Flir. Aeroflex. That's the culture. >>Your program has not a single comment, no indication of purpose, >>version, usage, authorship, limitations, or context. [quoted text clipped - 3 lines] >Largely the code is self-documenting, something you can do in C, >but need a whole lot of cryptic comments for in ASM. No language is self-documenting. Code tells what is done; comments tell why it was done. C programmers hate to comment as part of their mentality and culture. The comments are more important than the code. And my comments are not cryptic. >>It looks like >>monkeys pounding on typewriters, and is literally "code" in the sense [quoted text clipped - 7 lines] >The whole problem is that you do not write in C, so you cannot read the source, >it seems Greek to you. I've coded a little in C, and read a lot more. Most C programs are undisciplined, which may be OK for some apps, but not for mine. >So learn it first. No thanks. What I'm doing works far too well. >In the meantime, look at this (as to subject related) > http://www.xtremedatainc.com/index.php >100x speed, no multi cores needed. Hardly an embedded system. John >>In the meantime, look at this (as to subject related) >> http://www.xtremedatainc.com/index.php >>100x speed, no multi cores needed. > >Hardly an embedded system. We were discussing personal computers with multi core processors. Versus other solutions. Their solution, a simple plug in in the socket of an existing mother board, can give some database software up to 100 x speed increase. You stated that all other's software is crap these days, added some test instruments as example... I dunno, and I cannot speak for things I have not tried, but *Linux*, and many, if not most, apps running on it, including my own, work without crashes, do what they are supposed to do, and are written in C. Many people contribute / work on the code, nobody seems to have the incredible problems you suggest one should have understanding that code... When I got an email from a researcher saying: 'You forgot to increment 2 pointers in your soft', I felt a bit silly (I did rewrite it, and forgot that, but it still worked 100% so tests did not show it). But the fact that somebody else, to whom it is _new_ code, can just read it. and find an error, sort of destroys your argument, as that code was hardly commented, just self documenting. For me, embedded, not embedded, it makes little difference with Linux. A Linksys router is also an embedded system, runs Linux, and let's see: grml: # telnet wap Trying 10.0.0.152... Connected to wap. Escape character is '^]'. BusyBox v0.60.0 (2007.05.29-12:11+0000) Built-in shell (msh) Enter 'help' for a list of built-in commands. # uptime 18:40:19 up 43 days, 1:28, load average: 0.05, 0.01, 0.00 43 days is not bad for a box that is accessible by the whole world, runs a http server from a SD card, a WiFi access point, with code added and modified by me. And it is only 43 days because I pulled the plug on it 43 days ago, not because it crashed. Strange, I could just read that C source, and adapt it. MIPS processor, source cross compiled on a x86 Linux box. Now if it had been ASM then you'd have to port, or rewrite, a gigabyte or so of source. C is cool :-) >>>In the meantime, look at this (as to subject related) >>> http://www.xtremedatainc.com/index.php [quoted text clipped - 4 lines] >We were discussing personal computers with multi core processors. >Versus other solutions. http://www.electronista.com/articles/08/07/01/intel.thousand.core.chips/ http://blogs.intel.com/research/2008/06/unwelcome_advice.php "The preferable model, and easiest for a mere human coder to deal with, is one program (thread) on one processor. My desktop has 1,095 active threads under Vista at this moment. It took Microsoft more labor to build Vista to manage those threads than the Apollo moon project required. With lots of (X86-compatible) processors, I like the idea of the OS handling the job more than expecting commercial apps to do the job right. The past five year history of PC threading/multi-core is an example of the current way thats not moving fast enough. 2. Use the terrascale processor pool for general purpose, I/O, comms, and graphics processing. If there arent enough active threads, put the processors to sleep. The easiest set of applications to harness terrascale processors are commercial server applications like databases, web servers, and apps that already are well-threaded. That suggests Xeon deserves terrascale first. However, a couple of decades of systems engineering have gone into excruciatingly complex code to share a small number of cores. If the OS can give every thread its own (virtual) memory, OS, and processor resources, the need for processor contention management gets much simpler." John >http://blogs.intel.com/research/2008/06/unwelcome_advice.php > >"...My desktop has 1,095 active threads under Vista at this moment. It took Microsoft more labor to build Vista to manage those threads than the Apollo moon project required." You might be interested in my comments about the engineering behind the Apollo moon project. It's at HTTP://WWW.GUYMACON.COM/ENGINEER/HISTORY/INDEX.HTM (Scroll down part the sections on Thomas Edison and WWII Liberty Ships). SignatureGuy Macon <http://www.GuyMacon.com/> >>http://blogs.intel.com/research/2008/06/unwelcome_advice.php >> [quoted text clipped - 9 lines] >(Scroll down part the sections on Thomas Edison and >WWII Liberty Ships). Yes, that claim was silly. It cost about $150 million to write NT as of its first public release. I can't imagine that Vista cost more than a billion or so. John >>http://blogs.intel.com/research/2008/06/unwelcome_advice.php >> [quoted text clipped - 6 lines] > > HTTP://WWW.GUYMACON.COM/ENGINEER/HISTORY/INDEX.HTM If this had been written in lower case, my newsclient (Pan) would have rendered it as a clickable link. As it is, I'll have to cut and paste. )-; ...<reading>... ARRRRGGGGHHH!!!!! THERE IS NO APOSTROPHE IN THE POSSESSIVE ITS!!!!!!!!!!! (Apollo, paragraph 4) But just FWIW, I do my best to get the PHB to plan and organize, but alas, I swim upstream. Thanks, Rich >ARRRRGGGGHHH!!!!! THERE IS NO APOSTROPHE IN THE POSSESSIVE ITS!!!!!!!!!!! D'OH! (hangs head in shame) Note to self: [1] Prufreed before posting. [2] Smoke crack *after* posting. SignatureGuy Macon <http://www.GuyMacon.com/> >>>http://blogs.intel.com/research/2008/06/unwelcome_advice.php >>> [quoted text clipped - 13 lines] >ARRRRGGGGHHH!!!!! THERE IS NO APOSTROPHE IN THE POSSESSIVE ITS!!!!!!!!!!! >(Apollo, paragraph 4) How very strange, i read it as the contraction. (It is). >But just FWIW, I do my best to get the PHB to plan and organize, but alas, >I swim upstream. > >Thanks, >Rich > ... > The .TITLE and .SBTTL directives build entries in the table of [quoted text clipped - 3 lines] > > See the difference? Well, ASM can be as cryptic to one who has not memorized the instruction set. Come on, John, admit it - you like it because you can use CAPS LOCK. ;-) Cheers! Rich > Your program has not a single comment, no indication of purpose, > version, usage, authorship, limitations, or context. It looks like [quoted text clipped - 3 lines] > does. If it were non-trivial, or important, all this would be much > worse. And all caps is any better? Gack, how can you stand to read that? It makes my eyes burn... Now here's some code that's easy on the eyes (partial excerpts, the complete file is 21kB). -=-=-=- ; VIEWBMP.ASM -- opens and displays the specified bitmap file. ; Loads the specified bitmap file, displays some specs on it ; then views it on the graphics screen. ; ; /? = prints help screen, ; /F = Fast mode (skips spec screen, goes right to the graphics) ; ; Returns exit code 0 if everything went correctly or ; the help screen was displayed, 1 if a general error occured, ; any other number if an MS-DOS error occured. ; .MODEL small .8086 DataSeg SEGMENT word ; ; -=-=- Variables -=-=- ; runSlow word -1 ; boolean, /F turns off hasFN word 0 ; boolean set with filename token fileHndl word ? ; MS-DOS File handle bitHdr1 bitFileHeader {} ; ; -=-=- Strings -=-=- ; msgFailFl byte "Invalid file name: $" msgFailFF byte 13,10 byte "Invalid file format.",13,10,"$" msgFailBF byte "Bad file name or cannot open file.",13,10 DataSeg ENDS ; ; -=-=- Code begins here -=-=- ; CodeSeg SEGMENT ASSUME CS:CodeSeg,DS:DataSeg,ES:DataSeg cld push ds pop es ; copy DS to ES manually... ; ; Get own Program Segment Prefix and retrieve the first command line ; parameter from it. ; mov ah,62h int 21h ; get PSP in BX mov ch,0 push ds ASSUME CS:CodeSeg,DS:nothing,ES:DataSeg mov ds,bx mov cl,ds:[80h] ; get and save length inc cx ; scan to one past the end ; so the last token is valid mov si,81h ; DS:SI = command line . . . ; ; -=-=- Procedures -=-=- ; ; ; copyToken: finds the next token in the input string and copies it ; to an the output string. ; Input: ; DS:SI = input string location, ; ES:DI = output string location, ; CX = (unsigned) maximum number of bytes to scan. ; Make sure source has as much as CX bytes to scan and destination ; has as much as CX+1 free capacity allocated. ; Returns: ; DS:SI = delimiter which terminated this token, ; ES:DI = end of token copied, ; CX = number of bytes remaining. If CX = -1, copy ran out of ; bytes and the return string is probably incomplete. ; copyToken PROC near USES ax ASSUME CS:CodeSeg, DS:nothing, ES:nothing jcxz loopOut ; trivial case nextChar: lodsb ; get a character call isDelimiter jnz outChar loop nextChar ; keep going until a token is found jmp loopOut ; didn't find one, leave outChar: ; found a token, copy it stosb ; copy the first char dec cx jz loopOut nextCharT: lodsb call isDelimiter ; keep going until a delimiter jz outCopyT ; is found stosb loop nextCharT jmp loopOut outCopyT: dec si outCopy: ret loopOut: mov cx,-1 ; loop fell through, set CX = -1 jmp outCopy copyToken ENDP ... CodeSeg ENDS END -=-=-=- Much easier to read, if I do say so myself. Tim SignatureDeep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms >> Your program has not a single comment, no indication of purpose, >> version, usage, authorship, limitations, or context. It looks like [quoted text clipped - 6 lines] >And all caps is any better? Gack, how can you stand to read that? It makes >my eyes burn... I've been programming in uppercase since before there was a lowercase. 68K assembly is really an elegant language; I wouldn't program any Intel machine in assembly. .SBTTL COMMAND INTERPRETER ; A COMMAND LINE CAN CONTAIN ANY NUMBER OF COMMANDS, SEPARATED ; BY SEMICOLONS. THE LINE IS TERMINATED BY A NULL. SERIAL INPUT ; CHARACTERS MUST BE FIRST EDITED THROUGH THE 'CROOK' TABLE. ; EACH COMMAND HAS A MAIN TOKEN, FOLLOWED BY EITHER... ; ; TERMINATOR: IT'S A SIMPLE ACTION OR INQUIRY STatus ; A LETTER: WE ASSUME A 2-LETTER SECOND TOKEN LOad SInewave ; A NUMBER: A NUMERIC ARG 3Set 4096 ; A TOKEN IS A STRING OF AT LEAST 2 LETTERS. ONLY THE FIRST TWO MATTER. ; THIS EDITION ALSO ALLOWS COMMANDS OF THE FORM 2Set R3 ; ENTER HERE WITH A6 AIMING AT A LINE TO EXECUTE. IT MAY ; BE ANY LENGTH BUT *MUST* HAVE THE NULL TERMINATOR. ; WE GENERATE THE REPLY STRING DIRECTLY TO THE SPI TRANSMITTER, ; WITH BASIC RULES... ; ; A COMMAND GENERATES REQUESTED DATA, "OK", OR "??" ; SEMICOLON ECHOES AS SEMICOLON ; THE FINAL NULL ECHOES AS CR/LF ; IF ANY COMMAND THROWS THE "??" ERROR, WE TERMINATE. ; 'SCOUT' AND 'LINUX' OUTPUT CHARS AND LINES. IF 'QUIET' IS SET, WE ; WILL *NOT* GENERATE SERIAL REPLIES. THIS LETS US SILENTLY EXECUTE ; STRINGS FROM EPROM IF WE WANT TO, DEMOS FOR EXAMPLE. ; SUB 'EVAL' SETS CC'S BASED ON THE CHAR AIMED AT BY A6... ; ; Z NUL, END OF COMMAND LINE BEQ ; N NUMBER BMI ; V SEMICOLON COMMAND DELIMITER BVS ; C LETTER BCS ; A0 AIMS AT TEXT TO SEND ; A2 SCANS COMMAND TABLE ; A3 POINTS TO COMMAND PARAM ; A6 AIMS INTO TEXT BEING PARSED << SUPER-GLOBAL << ; D0 IS WORD OR LONG NUMERIC ARG ; D0:D1 IS A 64-BIT "FLOATING" VALUE ; D3 ACCUMULATES TOKEN CHARS ; D4 IS CURRENT ASCII CHAR ; ASSUME COMMAND IS "ASet ON" BELOW... XCOM: TST.W SLASHR.W ; A REPEAT-COMMAND \ CHAR BEQ.S XCAT ; NEEDS A CRLF ZOT "$" ; FOR COSMETICS CLR.W SLASHR.W XCAT: TST.B (A6) ; SPECIAL CASE: NULL LINE BEQ X340 ; GETS 'OK' XNET: CLR.L D3 ; ZAP CHARACTER ACCUMULATOR CLR.B VERBOS.W ; CANCEL SPECIAL VERBOSE MODE JSR SLIDE.W ; SLIDE OVER ANY WHITESPACE BEQ XCRLF ; NULL : EXIT BVS.S XSEMI ; SEMICOLON : BLANK COMMAND BCS.S XLETR ; LETTER : 1ST CHAR OF VERB BMI.S XLETR ; NUMBER : TREAT AS LETTER HERE! BRA XERR ; DEFAULT : ERROR XSEMI: JSR SCOUT.W ; ECHO THE SEMICOLON IN D4 XSNIT: ADDQ.W # 1, A6 ; HOP TO NEXT CHAR BRA.S XNET ; AND TRY AGAIN ; GOT 1ST LETTER (OR POSSIBLY NUMBER, OR *) OF A VERB... XLETR: CMPI.B # "*", D4 ; VERY SPECIAL CASE: LXI *ID BEQ.S XSNIT ; IGNORE THE STAR! MOVE.B D4, D3 ; COPY 1ST CHAR OF VERB "---A" MOVE.L D3, D5 ; (SNAG A COPY FOR FAST DISPATCH) ADDQ.W # 1, A6 ; SKIP TO NEXT CHAR JSR EVAL.W ; AND ANALYZE THAT: ANYTHING BUT A BCC XERR ; LETTER IS A SYNTAX ERROR ; GOT SECOND LETTER XV2: LSL.L # 8, D3 ; MOVE 1ST CHAR HIGH "--A-" MOVE.B D4, D3 ; POKE 2ND VERB CHAR INTO D3 "--AS" ; FLUSH REST OF VERB XV3: ADDQ.W # 1, A6 ; SKIP TO NEXT CHAR JSR EVAL.W ; AND EVAL IT: BCS.S XV3 ; FLUSH ADD'L LETTERS JSR SLIDE.W ; FLUSH SPACES BCS.S XVAT ; SKIP FOR ALPHA TOKEN ; IF WE DON'T HAVE AN ALPHA ARG, ALIGN FOR TABLE LOOKUP... SWAP.W D3 ; MOVE VERB UP "AS--" BRA.S XLOOK ; AND LOOK UP THE COMMAND ; HERE, WE SEEM TO HAVE A SECOND TOKEN... XVAT: LSL.L # 8, D3 ; MOVE 2 CHARS LEFT "-AS-" MOVE.B D4, D3 ; ADD NEW, 3RD CHAR "-ASO" ADDQ.W # 1, A6 ; SKIP TO 4TH CHAR JSR EVAL.W ; AND TEST IT... BCS.S XVIX ; A LETTER IS GOOD BMI.S XVIX ; BUT ALLOW NUMBERS, TOO... BRA XERR ; ANYTHING ELSE CRASHES. XVIX: LSL.L # 8, D3 ; MOVE 3 LETTERS UP "ASO-" MOVE.B D4, D3 ; AND POKE IN 4TH "ASON" ; FLUSH THE REST OF THE 2ND TOKEN... X2FL: ADDQ.W # 1, A6 ; SKIP TO NEXT CHAR JSR EVAL.W ; AND EVAL IT: BCS.S X2FL ; FLUSH ADD'L LETTERS ; LOOK UP THE COMMAND IN THE 'TOKENS' TABLE ; D3 IS SQUASHED TOKENS; D5 IS FIRST LETTER OF FIRST TOKE. XLOOK: SUBI.W # "0", D5 ; MAP CHARS 0-UP ANDI.W # 63, D5 ; TO 0..63 ASL.W # 1, D5 ; MAKE WORD INDEX MOVEA.W D5, A2 ; AND POINTERIZE MOVEA.W SPEEDY(A2), A2 ; PLUCK SEARCH START FROM TABLE MOVE.W # XLEN, D7 ; PRELOAD CONSTANT, ENTRY SIZE MOVEA.W # UNLIM, A5 ; WE'LL SEARCH THE NORMAL LIST TST.W UNLOK.W ; BUT IF THE PASSWORD HAS BEEN SEEN, BEQ.S XSCAN ; WE'LL DO THE HIDDEN MOVEA.W # XTEND, A5 ; CAL COMMANDS TOO XSCAN: CMP.L (A2), D3 ; TRY FOR A 4-CHAR MATCH BEQ.S XMATCH ; SKIP ON SUCCESS ADDA.W D7, A2 ; NO MATCH, HOP TO NEXT ENTRY CMPA.W A2, A5 ; AND CHECK FOR END-O-LIST BNE.S XSCAN ; NO, KEEP TRYING BRA.S XERR ; OR DECLARE AN ERROR XMATCH: MOVE.W TTFLG(A2), D3 ; GRAB THE FLAGS WORD... AND.W C_OPT.W, D3 ; IS THIS COMMAND ALLOWED? BEQ.S XERR ; MAYBE NOT! MOVEA.W TTPTR(A2), A3 ; TOKEN MATCHES! EXTRACT POINTER MOVE.W TTPAR(A2), TFLAG.W ; STASH OPTIONAL PARAM WORD, TOO MOVEA.W TTACT(A2), A4 ; FETCH AND JMP (A4) ; CALL THE HANDLER ; COMMAND ROUTINES MUST EXIT THROUGH XOK, XDONE, OR XERR BELOW: XOK: DUMP T_OK ; SEND 'OK' TEXT ; NOW FLUSH ANY REMAINING JUNK IN THIS COMMAND XDONE: JSR EVAL.W ; EVAL CHARACTER (A6) BEQ.S XCRLF ; NUL : ECHO CRLF AND TERMINATE BVS XNET ; SEM : PROCESS NEXT COMMAND ADDQ.W # 1, A6 ; IGNORE ANYTHING ELSE AND BRA.S XDONE ; HOP TO NEXT CHARACTER X340: DUMP T_340 ; SINGLE <cr> EVOKES "T34x" PROMPT BRA.S XCRLF ; COMMANDS JUMP HERE TO DECLARE AN ERROR XERR: CLR.W QUIET.W ; (JUST IN CASE A DEMO HAS AN ERROR) DUMP T_ERR ; "??" ; END-OF-LINE : DUMP FINAL CR/LF AND EXIT XCRLF: JSR CHUCK.W ; UPDATE ALL CHANNELS! ; THIS VERSION USES THE FPGA AUTO-UPDATE HARDWARE. WHEN WE POKE 'X_AUP', IT ; STROBES ALL CHANNELS THAT DO NOT HAVE THEIR 'SU' BITS SET. MOVE.W D3, X_AUP.W ; BANG? DUMP T_CR ; ECHO FINAL CR/LF RTS ; AND WE'RE DONE! ; SUB TO SKIP WHITESPACE. THIS LEAVES WITH NEXT NON-WHITE ; CHAR IN D4, WITH CC'S SET APPROPRIATELY. SLIDE: CMPI.B # SK, (A6)+ ; GOT A SPACE? BEQ.S SLIDE ; IGNORE AND RETRY SUBQ.W # 1, A6 ; OOPS, BACK UP! ; SUB TO EVALUATE THE CHARACTER (A6) AND SET CC'S EVAL: MOVEM.L D7 A2, -(SP) ; SAVE STUFF CLR.L D4 ; NAB CHAR POINTED TO BY A6 MOVE.B (A6), D4 ; INTO D4, AS CLEAN LONG MOVEA.W D4, A2 ; MAKE POINTER MOVE.B ELUT(A2), D7 ; LOOK UP CONDITION CODES IN TABLE MOVE.W D7, CCR ; AND LOAD CPU CC BITS MOVEM.L (SP)+, D7 A2 RTS NUM = NBIT ; BMI NUMBERS 0..9 + - . LTR = CBIT &n |
Enable EMail Alerts
Start New Thread
Reply to this Message