Re: What makes a compiler, was Is Assembler

"Walter Banks" <walter@bytecraft.com> wrote in message
>> > [The Burroughs compilers are real Algol compilers. If you're not
>> > worried
>> > about optimization, it's quite possible to generate adquate code on the
>> > fly from each grammar rule. See Irons classic 1961 paper on Syntax
>> > Directed Translation. -John]
>> ...


> 20 plus years ago we implemented a single pass compiler that was
> implemented as parser that front ended on the back end of a macro
> assembler. All the symbol table management was done in a single symbol
> table. Code was translated directly into machine code with no
> intermediate form (including no asm) It was surprisingly efficient and
> very quick.
>
> For full C this approach would likely be very difficult. The problem
> as I see it would be to change C back into the macro form that K&R
> were using. This would involve a lot of context sensitive grammar and
> code sequences.


Yes.


the problem as I see it would be the existence of certain x86 specific
issues (worse for x86-64), where some intermediate stage would
presumably be necessary (namely, to flip around x86 arguments, or
reorganize x86-64 arguments, ...).


on x86 and x86-64, this would seem to require some variant of the
"pascal" calling convention (left-to-right argument evaluation,
resulting in effectively a reversed argument list on the stack).


although, granted, one could allow an intermediate tree form at the
expression level, which could resolve this problem (I had assumed
directly generating output from the parser).


...


> The modern alternative might be to use heuristic code generation to
> replace the multiple optimization layers. Cherry pick the easy stuff
> and maybe generate machine code directly. This would probably produce
> reasonable code and has to potential to be quick.


yes.


my current middle/lower compiler is based primarily on hueristic code
generation, where it takes 2 passes (per-function, the overall process is
single-pass):
the first pass maps out code (figures out which registers to save, ...);
the second pass generates the output.


both passes behave the same, only the first pass has output disabled and
serves to store bits of information about what happens.




now, this 2-pass approach could be avoided by either never using callee-save
registers, or always being sure to preserve all of them, ...

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