DotGNU compiler project

Kirill Kononenko <kirill.kononenko@gmail.com>
Sat, 25 Apr 2009 21:31:15 +0400

          From comp.compilers

Related articles
DotGNU compiler project kirill.kononenko@gmail.com (Kirill Kononenko) (2009-04-25)
| List of all articles for this month |

From: Kirill Kononenko <kirill.kononenko@gmail.com>
Newsgroups: comp.compilers
Date: Sat, 25 Apr 2009 21:31:15 +0400
Organization: Compilers Central
Keywords: tools
Posted-Date: 25 Apr 2009 14:53:39 EDT

You might find interesting to have a look to DotGNU. This is an
implementation of .NET ECMA-335 by Free Software Foundation. Most of
its part has been started by Rhys Weatherley.
The tools you might find interesting are the TreeCC, Portable.NET, and
libJIT. TreeCC does abstract tree parsing:
http://rholbert.colug.net/english/FSM/ISSUE02/treecc.pdf . We use it
for our C#/Java/C compiler (CSCC). The CSCC compiler generates
assemblies in the Common Intermediate Language. Portable.NET is a
Common Language Runtime:
http://www2.sys-con.com/ITSG/virtualcd/Dotnet/archives/0103/weatherley/index.
html


Currently Portable.NET after many years of development supports a real
advanced JIT compiler. This JIT is based on our library libJIT. libJIT
support advanced JIT compilation:
http://www.gnu.org/software/dotgnu/libjit-doc/libjit.html


This is my opinion about libJIT: "LibJIT is probably the best free
library for development of advanced Just-In-Time (JIT) compilation in
Virtual Machine implementations, Dynamic programming languages, and
Scripting languages. Unlike GNU lightning or LLVM, libJIT Just-In-Time
compilation library is both platform independent and remarkably easier
in usage." I am quiet negative about LLVM for various reasons, which
are off-topic for this mailing list.




libJIT source code also contains an example of a simple JIT by Norbert
Bollow, and a JIT of Dynamic Pascal.


Compiling of the DotGNU source code is quiet standard:


./auto_gen.sh
./configure (./configure --with-jit for Portable.NET source code)
./make all


Currently, there are three developers of libJIT and PNET JIT. These
are Klaus Treichel, Aleksey Demakov (he is also in this mailing list),
and myself.


I think you can find interesting to use libJIT or contribute to it. It
uses a SSA based Intermediate Representation. My own project is the
libjit-linear-scan-register-allocator(http://code.google.com/p/libjit-linear-
scan-register-allocator/)
basically, it is a support in libJIT of advanced JIT compilation.
There is an extended linear scan register allocation, linear scan
register allocation, bin packing register allocation, for IA-32 only
at this time. There is also data-flow and control-flow analysis( for
example, dead-code elimination). In short, I already have higher
results in our benchmark PNETMARK than Mono. Still it is of course
much inferior at this time than the Microsoft .NET. It was very easy
to add support of dead-code elimination I spent less than a week for
this. Maybe you might find interesting and fruitful to implement in
libJIT this, for example:
http://code.google.com/p/libjit-linear-scan-register-allocator/wiki/ListOfTOD
Os
. Like:


- Improve dead code elimination even further for benchmarks
- Constant folding
- Loop-unrolling
- Loop-invariant code motion
- Common sub expression elimination


I would not recommend this if it was not interesting for myself to-do
this too. (I have no enough time myself for this work at this time.
Because I am documenting, and writing research papers about my current
work...). I think these are really interesting things to experiment
with. It might take 1-2-3 weeks for you to implement this in libJIT of
quiet relax work. Also it is really interesting to see how benchmark
go above with such easy thing (although I don't believe in benchmarks,
I know how often various projects trick them to get a marketing
advantage to other product)






Thanks,
Kirill


--
http://code.google.com/p/libjit-linear-scan-register-allocator/


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.