Re: How to generate object code

Eliot Miranda <eliotm@pacbell.net>
Tue, 23 Oct 2007 11:58:14 -0700

          From comp.compilers

Related articles
How to generate object code mudgen@gmail.com (Nick Mudge) (2007-10-21)
Re: How to generate object code santosh.k83@gmail.com (santosh) (2007-10-22)
Re: How to generate object code gah@ugcs.caltech.edu (glen herrmannsfeldt) (2007-10-21)
Re: How to generate object code eliotm@pacbell.net (Eliot Miranda) (2007-10-23)
Re: How to generate object code cfc@shell01.TheWorld.com (Chris F Clark) (2007-10-24)
| List of all articles for this month |

From: Eliot Miranda <eliotm@pacbell.net>
Newsgroups: comp.compilers
Date: Tue, 23 Oct 2007 11:58:14 -0700
Organization: AT&T http://yahoo.sbc.com
References: 07-10-064
Keywords: assembler
Posted-Date: 23 Oct 2007 23:44:35 EDT

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]



Post a followup to this message

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