What to put behind my front-end?
Michiel
I'm working on a compiler for a new language with a colleague. I have
described it briefly in an earlier thread (Number of compiler passes).
For now, its purpose is research, not practical use. And this research
would not require the compiler to produce anything further down the
chain than the AST + symbol-table. However, because we wanted to see
the darn thing actually produce an executable (it's more fulfilling),
we decided to generate C++ code.
We're now finished with the translator, and I'm happy to say that it works
as expected. Of course, the research continues.
However, I have plans to turn this project into a 'real' compiler
somewhere down the line. And that means abandoning the C++ translation
and using a real intermediate language and back-end, so we can
generate more efficient code.
I would like your opinions on which existing IL to use. Or perhaps someone
could point me to a detailed comparison of ILs and back-ends.
* It should be open source, because we plan to release the compiler under
GNU GPL when it is ready.
* Our compiler is written in C++, so if there is a back-end that takes some
C/C++ structure, that might work. But I'm equally willing to use a textual
intermediate representation, which would also have various advantages.
* The language is still very limited, but we're slowly introducing the
possibility for more complex custom data-structures, so the intermediate
language should not be equally limited.
Denis Washington pointed me to LLVM, which seems a likely candidate. But I
would like to make a more informed decision.
Thanks in advance for your reply!
--
Michiel Helvensteijn
kamal
> I'm working on a compiler for a new language with a colleague. I have
> described it briefly in an earlier thread (Number of compiler passes).
> I would like your opinions on which existing IL to use. Or perhaps someone
> could point me to a detailed comparison of ILs and back-ends.
>
> * It should be open source, because we plan to release the compiler under
> GNU GPL when it is ready.
>
> * Our compiler is written in C++, so if there is a back-end that takes some
> C/C++ structure, that might work. But I'm equally willing to use a textual
> intermediate representation, which would also have various advantages.
try this:-
http://gcc.gnu.org/projects/tree-ssa/#documentation
> * The language is still very limited, but we're slowly introducing the
> possibility for more complex custom data-structures, so the intermediate
> language should not be equally limited.
>
IMs are designed to abstract out the front-end, so that they can be re-
used for other front-ends.
> Denis Washington pointed me to LLVM, which seems a likely candidate. But I
> would like to make a more informed decision.
>
depends on whether you want to use LLVM's optimization framework.
regards
-kamal
Richard Pennington
> Hi,
>
> I'm working on a compiler for a new language with a colleague. I have
> described it briefly in an earlier thread (Number of compiler passes).
> Denis Washington pointed me to LLVM, which seems a likely candidate. But I
> would like to make a more informed decision.
I strongly second LLVM.
I'm making a back end for the C/C++ parser Elsa
( http://www.cs.berkeley.edu/~smcpeak/elkhound/ ).
I looked a little bit at SUIF (and MachSUIF) before I went to LLVM.
SUIF looked OK, especially after I was able to build it using a
current version of gcc, which took a bit of work. It seems that no one
is doing active development in SUIF, however, so unless to are very
self sufficient it may not be the way to go.
LLVM has several things going for it in my opinion:
* Berkeley-like licensing.
* Very active development community.
Really! And these people are very helpful, both on the mailing list
and the IRC channel.
I've submitted several problem reports and they are usually fixed
within a day or two. Not that there are a lot of bugs. I'm using
LLVM in an unusual way and tickling parts that may not be used often.
* Very clean and understandable structure.
* Strongly typed intermediate language.
Very useful when lowering an AST to IR. LLVM catches a lot of
mistakes.
* Easy to add optimization passes.
* Support for several targets.
x86/x86_64, mips, Sparc, ARM, ...
* A port of gcc/g++.
Very useful to see what kind of IR another compiler generates.
* A clean, library based structure.
I was able to combine LLVM libraries into a single front end
That parses, optimizes, links, and does inter procedural
optimizations, inlining, etc. of the IR very easily.
I started using LLVM in the beginning of December of last year and by
the end of the year was able to compile and run a non-trivial program
(bzip2).
I generally keep current with the LLVM sources and I have had very few
cases where the API has changed to the point that I've had to update my
code.
If you're interested, my stuff is described (sort of!) at http://ellcc.org
-Rich