[Mono-list] gcc front-end and portability

[John Zedlewski]

>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.

Tyson,
  Hmm... I don't see why you lose that by generating native code from
CIL, if you do it on the client machine.  You can verify and compile
everything at install-time, no?  That way we only incur the overhead of
compiling once.  I definitely agree, though, that the gcc backend will
be too slow for Java-style JIT-ing, but I really don't see an advantage
to the JIT model at all.

  Most of the new research JVMs have moved over to a 2-JIT model, where
you have one super-fast, but non-optimizing compiler and another slower,
optimizing one for frequently-used methods. IBM's Jalapeno
(http://www.research.ibm.com/jalapeno/publication.html) does this, as
does Intel's ORP (http://www.intel.com/research/mrl/orp/).  It might be
possible to use gcc for optimization, but a non-optimizing, custom
compiler for fast compilation on a handful of popular platforms.

  I just want to emphasize that it's really, really, really, really hard
to build a good, cross-platform optimizing JIT from scratch. In the 5-6
years that Java has been around, no open source or academic project has
managed to do it (Sable, OpenJIT, and LaTTe are all machine-specific and
they typically lose to the Sun, MS, and IBM JVMs by a factor of 2 in
benchmarks). I really don't se a reason to believe that Mono-CLI will do
better unless it starts from a strong foundation.  But, hey, maybe I'm
just too much of a cynic.

  --JRZ