[Mono-list] Gcc front-end?

Tyson Dowd trd@cs.mu.oz.au
Tue, 10 Jul 2001 22:07:52 +0200


On 10-Jul-2001, John Zedlewski <zedlwski@Princeton.EDU> wrote:
> Hi folks,
>   On the roadmap, it seems to imply that y'all are working on a
> completely new "JIT" compiler for the CLI.  I'm curious about why this
> is a better plan than writing a Gcc front-end for CLI bytecode.  As soon
> as a Linux x86 "JIT" comes out, somebody's going to complain about the
> lack of optimizations, somebody else will bitch about not having a Linux
> Alpha port, and ten more users will want ports to Solaris and IA-64.  At
> least, that's been my experience with OSS projects in the past ;)  Some
> old posts from the Mercury folks implied that they were able to do the
> Mercury->gcc interface in under 8,000 LOC.

The Mercury->gcc interface was a pretty easy binding because all the
hard work of translating Mercury to an intermediate form that was
basically compatible with gcc's internal data structures had already
been done.  All that was left was handling the impedence mismatches
between the two structures.  (I'm probably over-simplifying a bit).

If you are going to have a JIT, gcc is not going to be fast enough -- it
wasn't designed for it.  It certainly wasn't designed to be a
compilation server kind of application (which is what a JIT compiler is like).
For instance, gcc has trouble with compiling multiple files at once
(this is one of the problems with the Mercury->gcc binding, you can't
easily wipe clean the gcc data structures in process, you are expected
to start a new process instead).  

If you are saying forget JITting the code and just generate native code
from CIL, then it will probably work, but you lose runtime
verifiability, code mobility and all the other nice things that an
architecture neutral bytecode gives you.

>   Also, am I correct in believing that CLI is designed for more of an
> Ahead-Of-Time compiler with local caching of native code?  That's what
> all the MS marketing-speak seemed to imply (no interepreter or
> mixed-mode).

No interpreter, everything is either
	- jitted as required (at class load time I expect)
	- jitted as installed

Microsoft probably had an interpreter once for bootstrapping purposes,
but they aren't releasing one now.

I believe native code is cached during a single session (but not between
reboots) -- others think it isn't the case, but it seems to be that way
to me.  I'm not sure if there is any documentation on what actually
happens.

Tyson.