Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!usc!ucla-cs!valeria.cs.ucla.edu!wales From: wales@valeria.cs.ucla.edu (Rich Wales) Newsgroups: comp.os.msdos.programmer Subject: Re: Material on .ASM subtleties sought Keywords: .ASM optimization Message-ID: <37512@shemp.CS.UCLA.EDU> Date: 31 Jul 90 06:33:53 GMT References: <1068@ashton.UUCP> Sender: news@CS.UCLA.EDU Reply-To: wales@CS.UCLA.EDU (Rich Wales) Organization: UCLA CS Department, Los Angeles Lines: 79 In article <1068@ashton.UUCP> tomr@ashton.UUCP (Tom Rombouts) writes: What are the main priciples in optimizing .ASM code? (Down to the clock ticks level) What type of C constructs might typic- ally be worth attempting to hand optimize? And which ones not? Small sections of code that are executed over and over again are the best candidates for optimization of any kind (including replacement by assembly language). If a tight loop contains lots of array references, it may be worth your time to replace it with carefully crafted assembly code. Then again, before doing this, see if you can accomplish the same (or almost the same) thing by using pointers in C. A profiler program would be valuable in pinpointing those portions of a program which are taking up all the time. Remember, most of a program isn't run often enough to justify rewriting it in assembly language. Another reason to go to assembler would be if a section of code needs to run as fast as possible -- e.g., a nontrivial hardware interrupt handler that has got to do its task and be done with an absolute minimum of wasted effort; or a real-time application which needs to keep pace with external factors that simply will not wait. WHEN is it practical to go to assembly rather than a more portable language such as C? Basically, if there's a part of your program that just =has= to run as fast as possible, it's a candidate for assembly code. How can assembly be developed to make it re-usable and under- standable by others? This is really impossible to answer fully in 25 words or less. I'd say the key is to explain what you're doing in each procedure or nontrivial section of code -- so that someone could read just the comments and get the basic idea. It may help, every so often, to insert a few lines of commentary explaining what each of the registers is currently being used for. Any line(s) of code that isn't transparently obvious should be given a comment explaining what it does. And don't use comments like "add one to AX" on an "INC AX" instruction; make sure your comments add something, don't just translate line-by-line into English. Actually, I think high-level language writing would be significantly improved if people put the same amount of effort into their documenta- tion as is essential to make rational sense of an assembly program. Two that seem good from quick scans are "The Zen of Assembly Language" and "Structured Assembly." Also, the recently released "Spontaneous Assembly" library by basetwo looks interesting. Peter Norton's book is pretty good on structured techniques, but contains almost no information on using it assembly in conjunction with other languages. Of the above, I'm familiar only with "The Zen of Assembly Language". I recommend this book highly. It's especially good at helping one under- stand the design of the PC and the impact that design has on the way a program works. I personally think assembly language is becoming a lost art, and that it can produce significant payoffs in time critical applications such as database processing or graphics display. Often true. However, it isn't worth it to write something in assembly language unless you can do a significantly =better= job than you could by writing the same thing in a high-level language. Also, since assem- bly language is at such a low level, you need to put more effort into your documentation than with high-level code, or else no one (not even =you=, a few months later) will be able to figure out =what= you were doing. Finally, assembly language is not portable -- another reason to do most of your coding in a high-level language and use assembly only for small things that need to be fast (or for low-level applications that are tied to the hardware and will never be ported anyway). -- -- Rich Wales // UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683 "Indeed! Twenty-four is the gateway to heroic salvation."