phipps@garth.UUCP (Clay Phipps) (11/29/88)
In article <2220@bucsb.UUCP> composer@bucsb.bu.edu (Jeff Kellem) writes: >In article <1961@crete.cs.glasgow.ac.uk> >orr@cs.glasgow.ac.uk (Fraser Orr) writes: >>I don't agree that there is ever any necessity to code in assembler. We >>have languages that produce code just as good as hand crafted assembler >>(such as C), so why not use them for this sort of thing. What you will need to learn to be at all effective in assembler will be useful in understanding how computer systems work, and in understanding things like code-generation for compilers. This makes learning at least one instruction-set's assembler worthwhile. Actually using that assembler may not be. If the consequences of errors are insignificant, and financial resources are limited, e.g., the compiler bought with your own money takes a few too many instructions to perform a snow-free update of the graphics display of a computer bought with your own money, and the worst that will happen is that you will update the screen flakily for some whizz-bang dazzler of a program you are writing, and it's all for fun, sure, go use assembler if you want. But the extra time spent debugging your assembly code might be put to better use by completing some important work, studying, partying, or just doing nothing. >Except, of course, in the case of real-time programming, >where speed/efficiency is of greatest importance (after correctness); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A very strange way ------------------------------------| to phrase a point of view that correctness is more important than speed. >as in some robotics development and data sampling. In 1975, "Navy Requirements Of A High Order Tactical Programming Language" curiously rated "Generate efficient object code" (score: 99) as more important than "Completely bugfree compiler" (score: 98). This was in an early stage of development that led to Ada. The Navy was then in the process of becoming committed to avoiding assembly code for real-time applications. Some experiences with development and modifiability of real-time systems, e.g., 2 very similar "data sampling" subsystems generally known as SONAR, created by comparable personnel, but one in assembly and the other in a "tactical" high-level language: CMS-2, seemed to reinforce the Navy's emerging belief that assembly code should be the exception, rather than the rule for its real-time systems. Now, whether new features were added to the new system to justify another processor and more memory, which then compensated for some of the lost "speed/efficiency", or vice versa, I don't know. >Now, though optimizing compilers are becoming more common, >we still don't have one that can produce all possible optimizations. I would prefer a system that takes a little more time to find the right threat or target, to a system that makes mistakes quickly/efficiently, especially if DoD is determined to deploy SDI. The truly paranoid might wish to disable their optimizer for some tasks, but the optimizer may be testable to a high level of confidence, whereas hand-written assembly code may not get that opportunity. Follow-ups might best be directed to "comp.society". [The foregoing may or may not represent the opinion of the U.S. Navy] -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps