koopman@a.gp.cs.cmu.edu (Philip Koopman) (12/06/88)
Please notice the new subject line, the old assembler line has fragmented into too many discussions (*please* edit your subject lines!) One good reason to learn assembler is to help the compiler. In a recently written C program, I was able to get a 50% speedup simply by looking at the assembler output of the C compiler (it was gcc on a Vax using -O-S) and changing the C code to help out the compiler. The problem is that the C compiler just couldn't handle some pointer references as well as I could by moving the memory contents to register variables. The bottom line is that the programmer *knows* what is supposed to happen, while an optimizing compiler must often make pessimistic assumptions to avoid getting burned in the general case. The resultant code runs faster on several machines with several different compilers, and is still completely transportable (or at least as transportable as C gets). Until compilers can actually understand the intent of the program (and not just a particular expression of the algorithm), then a good programmer can always beat a good optimizing compiler. The only question is one of payoff for the time invested. In my case 8 hours of fiddling was worth the speed gains. One of the neat things about using Forth to program stack machines is that the Forth code usually maps directly to hardware instructions. It makes the efficiency of the completed code more directly coupled to the source code. It may be an added burden at times, but it sure beats having to outsmart a C optimizer!!! Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor. --