This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CIL frontend for gcc
- To: Oskar Liljeblad <oskar at osk dot mine dot nu>
- Subject: Re: CIL frontend for gcc
- From: Per Bothner <per at bothner dot com>
- Date: 06 Sep 2001 10:22:27 -0700
- Cc: gcc at gcc dot gnu dot org
- References: <20010906113159.A3864@oskar>
Oskar Liljeblad <oskar@osk.mine.nu> writes:
> I have been thinking about making a Common Intermediate Language
> (CIL) frontend for gcc as a part of a master's work. (At least starting
> to work on it.) The frontend would take compiled CIL code (embedded in
> Windows PE libraries/executables) or "disassembled" CIL code and
> translate it into intermediate gcc code, very similar to the java
> byte-code frontend in gcj (if I understand things correctly).
>
> Is anyone involved with such a project already?
I have read that the Mono project (http://www.go-mono.com/) is
planning on a CIL -> native compiler using GCC. I don't believe
anyone is currently working on it, but you should probably contact the
people involved with Mono to at least let them know if you're working
on it.
The Java bytecode front-end uses the traditional statement-at-a-time
model, like the C and C++ front-end used to. That is the "parser"
would build a tree structure out of expressions, and then at each
"statement" boundary (i.e. control transfer) convert that to rtl.
The preference these days is to generate a complete tree for each
function/method before generating any rtl. Both the Java source
parser and the C++ front-end do that. (Unfortunately, they use differnt
tree nodes! E.g. the Java front-end represents an if statement using
a COND_EXPR, while the C++ front-end uses an IF_STMT. I find this
inconsistency and duplication unfortunate.)
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/