Mark Lentczner writes:
>
> Indeed, I use our own C++ unit testing framework to do the same,
> testing at each phase of the translation:
> lexer (text --> tokens)
> parser (tokens --> AST)
> compiler (AST --> instructions)
> method-builder (instructions --> bytecodes)
In part I think that the architecture you choose for your compiler
depends on what your objectives are. If you want to build an
optimizing compiler and generate native code, another structure
might be:
1. lexer (text --> tokens)
2. parser (tokens --> custom AST)
3. build symbol table and annotate AST
4. Lower AST
5. Build control flow graph
6. Build data flow graph (moves intermediate into a single
assignment form)
7. Do machine independent optimization (common subexpression
elimination, constant propagation, etc..)
Things get more complex and controversial from here. One might...
8. Generate instructions based on an infinite set of virtual
registers.
9. Move instructions to fill delay slots.
10. Allocate actual registers and generate spill code.
11. Output assembly
In a language like Java resolving symbols and scoping is complex (or
at least I find it complex). So the intial AST contains (result of 2)
declarations. The symbol table is built and the AST (e.g., symbol
and type nodes) is annotated with pointers/references into the
symbol table. In this process, declaration AST is removed.
Lowering the AST involves issues like hoisting expressions out of
method/function calls, building virtual function tables and
references into the virtual function table. What ever you need to
get an AST that consists more or less of branches,
arithmetic/logical and load/store operations.
Sometimes I miss compiler development. Too bad it's a dying art.
Ian
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/antlr-interest/
<*> To unsubscribe from this group, send an email to:
antlr-interest-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/