|How To Design A Code Generator firstname.lastname@example.org (Christian Parpart) (2002-03-17)|
|Re: How To Design A Code Generator email@example.com (Pietro) (2002-03-19)|
|Re: How To Design A Code Generator firstname.lastname@example.org (Dobes Vandermeer) (2002-03-21)|
|Re: How To Design A Code Generator email@example.com (Christian Parpart) (2002-03-21)|
|From:||Dobes Vandermeer <firstname.lastname@example.org>|
|Date:||21 Mar 2002 22:00:06 -0500|
|Posted-Date:||21 Mar 2002 22:00:06 EST|
Christian Parpart wrote:
> Hi folks,
> I was wondering if someone can tell me some information about
> code generators and its design. We're currently developing our
> own compiler (for an own language).
> As a sub project I've decided to split our compiler into front end
> and back end.
> While our front end (the language parser, semantic checker)
> seems closely finished, our back end is in a very early state.
> That Compiler Backend Library (CBL) is able to generate/manipulate
> syntax trees (definitions/symbols/expressions/statements).
> Now it should be also able to generate low level code (e.g. asm source,
> or binary).
> Does anyone know some other good sources, or informational sheets?
> I know GCC has its own back end, too. But it's written in plain C and
> really really very unreadable. We've written in C++.
Why not take a look at some of the other open-source projects
attacking this issue? My own isn't quite working yet, but you can see
LCC, Ximian's Mono, or dot-GNU. Most people these days seem to like
the tree-matching approach taken by LCC's iburg backend (converted to
C# in the Mono project).
An alternate approach is based on writing "dumb" (but simple) code and
optimizing it. This is the favorite approach down at the university
of virginia, where VPO and the Zephyr project seem to live. Since you
like C++, you could look at SUIF, which is written in C++; it has a
few optimizations and I think they had a working backend using VPO for
If you are targetting the intel cpu, you will probably find it
difficult to find working source code. Most projects seem to think it
wise to first target a really easy cpu (like sparc) and then move to
intel, at which point their entire scheme goes up in flames and they
never get it working completely.
Return to the
Search the comp.compilers archives again.