Re: How to generate object code

Nick Mudge wrote:
> Do compilers normally turn code into an assembly language and then run
> an assembler to to convert it into binary? Or does the compiler make
> its own representation and itself turn the representation into object
> code?
>
> How do assemblers turn assembly into object code? Does the assembly
> author have to know the binary numbers to translate the assembly into?
> [Some compilers do it one way, some do it the other. Unix compilers have
> traditionally compiled into assembler because early on there was a very
> fast assembler available.
>
> Re assemblers, of course they have to know the binary numbers in the
> computer's instruction set. -John]


As John says there are examples either way. But I strongly assert
that the _only_ right way to do it is to produce assembler and
assemble this separately? Why?


A lng time ago I wrote Smalltalk VMs that did bytecocde
interpretation.
    There were benefits if one wrote in C rather than assembler
(portablity, concision, debugging) but lots of speedups if one could
post-process the compiler-generated assembler (one could eliminate
redundant bounds checks on the bytecode dispatch switch, or even get
important variables into global registers - this before compilers like
gcc supported them directly). These tricks could yield cumulative
performance increases of 50%.


When I ported the VM from various Unix flavors (where the compilers
generate assembler) to Windows (which generated object code directly)
none of these techniques could be applied because although the
Microsoft compiler could be asked to spit out assembly code, the
assembly that it did produce was incorrect. If one assembled the
output it would only match the directly-compiled object code for
trivial cases. I presume that assembly was produced by decompiling
the object code. Because C->assembly->object was not the default path
its incorrectness was perhaps not noticed and certainly not corrected.


So if you're thinking of writing a compiler make it generate assembly
directly. It'll integrate better and be more extensible.
--
Eliot ,,,^..^,,, Smalltalk - scene not herd
[It certainly helps that Unix assemblers tend to be small and fast,
without macro languages or other addons that slow down assemblers
on other systems. If you really need macros, you can run your code
through m4 first. -John]

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