generating assembler

I have to disagree with any fixed inclination for or against generating
assembler code as opposed to binary. The best determinants of the
question actually seems to be the amount of manpower available to code,
test, and maintain the compiler.


When one person has to write a whole compiler from scratch (or nearly so),
the idea is to follow the old adage (due mostly to J.Levine):
"first make it work, then make it work fast; otherwise you wind up with a
fast lump of dog-meat." This is also true if the compiler-maintenance
crew has high turnover or low morale.
On the other hand, if you have a staff of people available to work on the
project, the clear winner is having the compiler generate binary, with
almost-assembler optional, because this gives the best compilation speed
without sacrificing too much functionality.


Realistically, when a compiler user looks at the assembler listing, they
are looking for two things: (a) whether the system is generating bad code;
and (b) whether there is something that the user can do to make the system
generate faster code. If the decision to emit binary instead of text
is made at a sufficiently low level, the pragmatic differences are
negligible once the code generator is debugged (a quick process because
by assumption we have somebody who eats, sleeps, and breaths code generation
working on it full time).


Then again, maybe I'm biased I work on large stuff (3.5 hours to compile
on 9 MHz ibm AT).


Kevin Thomas, thomas-kevin@Yale
[Aw, shucks, Kevin's too kind to attribute that aphorism to me -- it's been
said over and over, notably by the authors of Unix ifself. -John]
--

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