[Mono-list] Gcc front-end?

[Jay Freeman (saurik)]

John:

Yes.  Speaking about Microsoft's implementation:  While it caches compiled
code in memory (obviously), it will not (for version 1 at least, future
support has been indicated) cache the code it compiles during execution onto
disk between executions.  It does not do any interpretation or mixed-mode
execution (the byte codes weren't designed to make this easy, anyway).
There is also a "pre-JIT" compiler that can be executed either manually or
from an installation program to compile the code during installation, sign
it (to verify that evil code wasn't plopped in its place), and cache it
away.

The question I have about what you are saying is: if you do this, is there
going to be a good way to get gcc to execute on in-memory sets of byte codes
(as we just downloaded them from whatever site into memory, or maybe someone
used Reflection.Emit to compile on-the-fly into memory) to output an
in-memory binary (for purposes of actual execution)?  From what I've seen of
GCC it looks like god-forsaken, hacked-together, monolithic technology that
only kicks ass at what it does because everyone uses it and keeps it up to
date with all of the latest hacks.  The inability to quickly seperate out
its components for reuse actually seems to be a _feature_ accourding to what
I've heard from Miguel in conversations recently (having to do with being
able to... convince... companies to release their source code, as to get
their product working it needed to actually _become_ gcc rather than just
_using_ gcc for a single purpose, such as a back-end compiler).  While I
really would love to see a gcc front-end, I don't see how this deals well
with the JIT question.

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

----- Original Message -----
From: "John Zedlewski" <zedlwski@Princeton.EDU>
To: <mono-list@ximian.com>
Sent: Tuesday, July 10, 2001 1:32 PM
Subject: [Mono-list] Gcc front-end?


> 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.
>
>   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).
>
> Thanks!
> --JRZ