|Compiler Phases firstname.lastname@example.org (christopher diggins) (2004-01-22)|
|Re: Compiler Phases email@example.com (2004-01-31)|
|Re: Compiler Phases firstname.lastname@example.org (dablick) (2004-02-01)|
|From:||email@example.com (Torben Ęgidius Mogensen)|
|Date:||31 Jan 2004 00:51:01 -0500|
|Organization:||Department of Computer Science, University of Copenhagen|
|Posted-Date:||31 Jan 2004 00:51:01 EST|
"christopher diggins" <firstname.lastname@example.org> writes:
> I am writing a compiler for my new language Heron using Heron
> itself. I was wondering if anyone has some ideas for a design for as
> simple a compiler possible using a declarative and object oriented
> language similar to Java or C++.
> The compiler can run slow as molasses, it can halt on the first error
> found and it can be a huge memory hog. It just has to be very simple
> to implement and understand as it will be read and worked on by people
> with are just learning Heron. I don't need very much detail at all, I
> just would like some ideas on what kind of design would be the path of
> least resistance for hand coding a compiler. Please do not post about
> using YACC etc., hand coding is a non-negotiable requirement for this
For hand-coding, you should use recursive-descent parsing, preferably
by using parser combinators (see, e.g.,
Construct an abstract syntax tree (instead of generating code during
parsing), as that makes the structure easier to understand and modify.
What comes after parsing depends a lot on whether you need to do
type-checking and what kind of machine you want to compile for
(register or stack based).
It is probably a good idea, regardless, to have a simplification phase
that implements some of the advanced features in the language by
simpler constructs in the language. This can come before or after
type-check depending on whether you want to simplify type-checking or
provide better error messages (in terms of the original program).
As a source of inspiration, you could take a look at Wirth's book
"Compiler Construction" (Addison Wesley, 1996), which describes a
project much as your above for Wirth's own language Oberon.
Return to the
Search the comp.compilers archives again.