| Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#1
| |||
| |||
| 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). 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 |
|
#2
| |||
| |||
| On Aug 17, 8:49 pm, Michiel <m.helvenste...@gmail.com> wrote: > 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 |
|
#3
| |||
| |||
| Michiel wrote: > 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). [snip] > 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 |
![]() |
| Thread Tools | |
| Display Modes | |
In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.