Re: Why do we still assemble?

hbaker@netcom.com (Henry G. Baker) writes:
> Other than sheer institutional inertia, why do we continue to compile into
> assembler code, then assemble the code into relocatable binary? Why don't
> we compile directly to relocatable binary and be done with it?


>[Easier for C compilers to provide asm escapes with underlying assembler]


Not all C compilers provide _asm directives (ours doesn't). Insertion of
assembly code pretty much kills all optimization. Furthermore, it
requires some mechanism for the user to find out how registers have been
assigned by the compiler and so forth, otherwise there's very little you
can do in the inserted assembly code.


On top of that, there's the issue of how do you write code that doesn't
conform to the C calling convention? _asm directives in C have to be
inserted into some function. I've had occasion to write assembly code
that couldn't be done that way. (Examples: low-level OS code that munges
with the machine state; fragments of code inserted by a debugger.)


> Con: This argument is, of course, pure hogwash for today's virtual memory
> systems.


I get irritated whenever anybody uses virtual memory to justify using tons
of memory. If you don't have the real memory, virtual memory is *SLOW*.
There is no substitute for just using less memory.


> Con: The compiler has to write out a very large file
> character-by-character. Worse still, the assembler has to read this file
> in character-by-character and then _reparse_ it. The cost of all of this
> character hacking, file I/O, and parsing rivals and usually exceeds the
> entire cost of compiling and assembling.


We have discussed many times in our compiler group that this reparsing can
be avoided by passing pre-parsed input to the assembler, with an assembler
option to tell it that's what it is getting. We haven't done it, though,
because all our measurements of compile speed show that most of the time
isn't spent in those areas; much more is spent in register allocation
(compiler) and object-file preparation (assembler).


> The net result of all of this is the current C compilers, with the notable
> exceptions of the Think C compilers on the Mac (and others of similar ilk)
> are slower than the Algol compiler on the 7094 in the early 1960's.


RISC compilers, of course, tend to do a lot more than those old compilers,
too. The PC-oriented compilers tend to be oriented more towards fast
compilation at the expense of runtime. Depends on what the compiler
vendor perceives his market wants.


Also, those old compilers never worried about retargets, either. Today's
open systems have had a pretty radical effect on where compiler-writers
put their priorities.


Another issue you didn't mention is third-party compiler vendors. If I
were them, I'd maybe rely on an assembler because it would speed up my
time-to-market for a new processor. (This is especially true of the Unix
market, where I can supply just the compiler and not worry about having to
supply linkers and such.)


Have you actually profiled those compilers to find out if assembly-parsing
is really where they are spending their time?
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com
--

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