tomr@ashtate (Tom Rombouts) (07/31/90)
I am a roughly intermediate C coder, and have linked in a variety of pre-written .ASM routines into small C applications. I now seek references on 8086 assembly language that are more than just teaching of opcodes. Specificly, my questions are: What are the main priciples in optimizing .ASM code? (Down to the clock ticks level) What type of C constructs might typically be worth attempting to hand optimize? (And which ones not.) And the most important (IMHO) questions of all: WHEN is it practical to go to assembly rather than a more portable language such as C? How can assembly be developed to make it re-usable and understandable by others? 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. Any experiences or comments out there? Any BBS collections of generic .ASM routines that are worth tracking down? Or might it be best to just keep attempting to perfect my C knowledge? (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.) Tom Rombouts Torrance Techie tomr@ashtate.A-T.com V:(213) 538-7108
wales@valeria.cs.ucla.edu (Rich Wales) (07/31/90)
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 <wales@CS.UCLA.EDU> // 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."hiebeler@heretic.lanl.gov (David Hiebeler) (08/04/90)
I'm currently writing some new software to control a plug-in cellular automata board for PC's (Cray-1 speeds for $2000, plug plug). ;-) This involves writing an interrupt routine to service the board, and some low-level I/O routines to transfer data between the PC and the board. I never got much into assembly language, since I'm fairly new to the PC scene. I've never written even a moderate assembly-language stand-alone program. What I *have* done, in writing my software (using Turbo C 2.0), is to go back and re-do some of my low-level C routines using inline assembly. I think Turbo C is great for that (maybe Microsoft is too, but I haven't used it). C will take care of passing parameters and so on; you can just write the simple bare-bones low-level stuff in assembler. That's the way it should be, in my opinion. I don't know what others think of this practice, but I've found it very useful; it allows me to code critical sections of code in assembly language, without having to learn all the nasty details about assembling a complete program. It's worked well so far, with no disasters to speak of. I think it also makes the development cycle a little easier; for example, I'll write a display routine in C which will be unbearably slow, but will allow me to test my package. When I know things are working, then I can go back and turn the C code in the display function into inline assembly, and the rest of my routines never see any difference in the interface -- it still looks like a C function to them. -- Dave Hiebeler | Internet: hiebeler@heretic.lanl.gov Complex Systems Group | Bitnet: userF3JL@rpitsmts MS B213, Theoretical Division | UUCP: crdgw1!automtrx!hiebeler Los Alamos National Laboratory / Los Alamos, NM 87545 USA