|Maintainable compiler design? email@example.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-07-27)|
|Re: Maintainable compiler design? firstname.lastname@example.org (Michiel) (2009-07-29)|
|Re: Maintainable compiler design? email@example.com (BGB / cr88192) (2009-07-29)|
|Re: Maintainable compiler design? firstname.lastname@example.org (Martin Ward) (2009-08-06)|
|Re: Maintainable compiler design? email@example.com (James Harris) (2009-08-06)|
|Date:||Mon, 27 Jul 2009 14:16:08 -0700 (PDT)|
|Posted-Date:||29 Jul 2009 08:37:47 EDT|
I am working with my pet language, defining grammar, building runtime
etc - the usual things.
However, as this is my first complier, I am worried that I'm not
organising the code well. Aside from the frontend/backend division, I
feel the compiler books I red are sort of hazy in regards to how to
solidly organize the compiler to ensure that it is easy to maintain.
Currently I am working with ANTLR on the grammar, while I'm writing
the runtime in C. My idea was to make the first version of the
compiler with ANTLR in Java (striking a compromise between ease of
implementation and performance).
I have also played around a bit with Flex and Bison as well as Racc
and Rex on the ruby side, but ANTLR felt pretty easy to work with, esp
with ANTLRWorks for debugging grammar.
Most compiler books by necessity run rather limited examples where
code generation is done directly by emitting strings by walking the
That sounds reasonable for small language examples, but would seem
like it would be quite a nightmare to walk through for a larger
language. Looking through the ANTLR docs, there are examples where
they run their generated AST through multiple rule definitions to do
optimizations and finally generation, which seems like a good idea.
Are there any best practices to keep the compiler easy to understand
and well organized?
Return to the
Search the comp.compilers archives again.