Optimizing in assembly language

As usual, the thread on "compiler's optimization vs. hand written
assembly" has flared up with lots of opinions (mostly dealing with
software engineering issues rather than dealing with the simple
predicate "is is possible to write faster code in hand written
assembly.")


Clearly, given the necessary resources (time, skill, etc.), an expert
assembly program *can* beat a compiler for a given *instance* of the
program. However, the software engineers rightly point out the
following problems:


1) The assembly code will only be optimal for one processor (e.g.,
moving from a PIII to a PIV breaks the optimizations). Recompiling
the HLL code (assuming a high quality compiler is available, it may
not be) generates new optimized machine code with very little effort.
The assembly code will have to be rewritten. Sometimes the assembly
code (on the older processor) is *still* better, but this is becoming
less and less likely as processors change (e.g., PII to PIII was okay,
but PIII to PIV was a whole different ball game).


2) Highly optimized assembly language code is the stuff that legends
(and case studies) are made of. Simple assembly language isn't
difficult to understand, but optimized assembly code (like high
optimized machine specific code, in general) is very difficult to
understand. Therefore, the likelihood of a large number of defects is
higher in optimized code (vs. simple code) *in any language*, but
certainly assembly.


3) Very few software modules are static; they require maintenance and
change. Highly optimized assembly code is often "sequence dependent"
and cannot be changed without rewriting large, unrelated (to the
change) sections. The result is often less-than-optimal code because
either the programmer doesn't change it or the changes break the
optimizations.


4) Very few people are good enough at assembly language to write the
kind of code that can consistently beat compilers.


5) etc. (fill in the blanks with your favorite argument against assembly.)


It *is* possible to write machine-specific optimized code in HLLs.
The Berkeley strings library for C stands out as a prime example of
code that does really well on 32-bit machines. However, the resulting
code has nearly all the defects of assembly language (portability to a
different CPU is about the only advantage). The optimizations may
very well break with a new version of the compiler and they may also
break with new CPUs.


Basically, it boils down to this: compilers are really great at
bookkeeping but lousy at dealing with the "big picture" (global
optimizations not withstanding). Humans (the "assembly coder") are
really great at the big picture and lousy with the details.


So here's my question: why can't we write an "optimizing assembler"
that lets the programmer specify machine sequences and the assembler
does the same kinds of "book keeping" that a HLL compiler would do.
Sure, optimization is a bit more difficult at this level and you'd
have to allow the programmer to disable the optimizations on a
statement by statement basis (since sometimes the programmer really
does know better). This would allow the programmer to do what they
know best while taking advantage of the current state of the art in
optimization technology.


Of course, the real problem is "who would be willing to write such a
thing?" (and maintain it.) But the idea seems interesting to me. Let
the machine choose the best instruction organization given a sequence
in machine code. Let the machine rearrange registers in instructions
to make better use of them (and move memory accesses into registers,
if needed). Let the machine eliminate dead code. Let the machine do
code movement to improve performance.


While some assembly programmers might find this whole process
offensive ("I don't want a compiler touching my beautiful code."), it
would allow "less than expert" assembly programmers to at least match,
and usually better the code emitted by a typical HLL compiler.


Many of the software engineering problems would remain (do you really
want to write a large amount of code in assembly?), but some of the
issues, like the appearance of new CPUs with their own idiosyncrases,
would diminish or go away entirely.


Randy Hyde

Return to the comp.compilers page.
Search the comp.compilers archives again.