Re: Why do we still assemble?

My experience has been that if you are doing systems-level programming on
a platform that is either experimental or poorly supported, then an
assembler intermediate--which can be run through a filter--can be a
necessity. This makes it possible to:


1.) Gain access to processor-specific features not
considered essential by the compiler writer.
Examples: a.) For the MAX/COSMOS operating
system written here at JPL, it was necessary
to filter the output of National Semiconductor's
C compiler for the 32032 processor so that the
final object module would be relocatable
and to use the "sb" register so that different
tasks could use the same text segment but have
individual data segments.
b.) I'm currently writing a native-code
Forth compiler in C++ for which I need to
generate global symbols for addresses within
functions. For MSDOS, this can't be done with
either Borland's or Symantec's inline assemblers;
an assembler intermediate is required.


2.) Work around bad code generation.


I certainly won't argue that an assembler intermediate is always
necessary--Henry Baker's points are certainly valid--but I will argue that
the capability of generating an assembler intermediate should be there.


Nand.Mulchandani@Eng.Sun.COM (Nand Mulchandani) writes:
|> Here is a data point on the subject of compilers that directly generate
|> object code :
|>
|> The new SunPro SPARCompiler 3.0 does not go through an assembler to
|> generate object code (the previous versions did). However, it has been a
|> major pain to handle things like asm() instructions in C and assembly
|> language inline templates. However, the assembler front-end that was put
|> into the code generator was designed to take a character buffer and
|> disguise it as a file so that the same code could be used to handle asm(),
|> inline templates, as well as assembly language that could come from a file.
|>
|> I personally feel that the compile time gain makes it worth doing direct
|> object code formatting, but it really complicates the code generator
|> design because whenever the code generator wants to emit anything, it
|> can't just do a "printf" -- it has to explicitly create a node with all
|> the right information on it. This has led to a general increase in the
|> amount of code in the code generator.




Considering the problems described, maybe it would be simpler to generate
intermediate assembler code for modules in which asm() statements are
encountered and otherwise directly generate object code.


--Loring Craymer
[That's exactly what Wizard C, the predecessor of Turbo C, did. -John]
--

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