Re: Why do we still assemble?

I wrote the linker and assembler for Coherent (a unix look alike by Mark
Williams where I no longer work.). There were two reasons why we won all
the Compiler speed benchmarks.


The first was that the Compiler generated object code directly unless you
ask for assembler. The trick there is that you write emit() statements
which have all the stuff required for assembler or object code and then
only produce the right one. To get more speed make emit() a macro. Now
produce two versions of the last phase of your compiler with different
versions of emit defined.


This is really a form of partial evaluation, you are projecting different
versions of the compiler's last phase specialized to producing commented
assembler or object code.


The second and more important reason (in terms of timing) was the linker.
The secret here was a philosophy I call "see file eat file". When you see
you need an object file get its length malloc enough room and read it in.
You won't run out of space on unix. Then do all the fixes and write it
out, its a little tricky to avoid seeks but not terrable. The result was a
screaming fast (by comparison) linker that used less than 5000 lines of C.
It REALLY should have been in C++ but we didn't use it for management
reasons and as a result if they want to go to something other than COFF
the best path will be a rewrite.


When linkers are slow its generally because they avoid "see file eat file"
and this forces them to seek around. The results can be thousands of times
slower. When I hear of the Microsoft linker running overnight (I never
tried it myself) I know that is what happened. Better to write your own
pager and encapsulate paging than to seek around data files.
--

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