|Position of an Intermediate Code Generator email@example.com (Chris Rowland) (2002-07-15)|
|Re: Position of an Intermediate Code Generator firstname.lastname@example.org (Torben Ægidius Mogensen) (2002-07-21)|
|Re: Position of an Intermediate Code Generator email@example.com (Hannah Schroeter) (2002-07-21)|
|Re: Position of an Intermediate Code Generator firstname.lastname@example.org (Marco van de Voort) (2002-07-31)|
|Re: Position of an Intermediate Code Generator email@example.com (Peter H. Froehlich) (2002-08-04)|
|From:||"Peter H. Froehlich" <firstname.lastname@example.org>|
|Date:||4 Aug 2002 11:17:26 -0400|
|Posted-Date:||04 Aug 2002 11:17:26 EDT|
On Tuesday, July 30, 2002, at 09:58 , Marco van de Voort wrote:
> What is in your opinion the use of the intermediate code, opposed to
> directly generating code from the syntax tree?
> [It depends how much optimization you want to do. If you want a simple
> code generator, producing code from the parse tree is fine. If
> you want
> to improve the code, you need something else that lets you reorganize
> the code without reference to the parse tree. -John]
Just to chime in, I think that a basic architecture in which you
handle two major intermediate representations is most appropriate
if you want to balance simplicity and (semi-)advanced
optimizations: AST and SSA. Here's how I would organized it:
1. Convert source text into abstract syntax tree.
2. Build symbol table information (organized in scopes, etc.).
3. Perform type checking and other static analyses.
4. Convert AST into SSA (or variant thereof).
5. Perform SSA optimizations and analyses.
6. Convert SSA into native code.
7. Perform machine-specific optimizations.
8. Convert native code into object code and emit.
At UCI, my upper division compiler course goes from source to AST
to native code (no optimizations) and Michael Franz's graduate
course goes from source to SSA to native code. From the experience
in these courses, it seems a good tradeoff to combine both
approaches as illustrated above (for something that is more than
just a term project and therefore less time-constrained).
Just my $0.02 of course,
Peter H. Froehlich ->[!]<- http://nil.ics.uci.edu/~phf/
OpenPGP: D465 CBDD D9D2 0D77 C5AF 353E C86C 2AD9 A6E2 309E
Return to the
Search the comp.compilers archives again.