Ken Fox wrote:
>
> I'd prefer us to tackle native code generation using C as the
> intermediate language instead of a JIT. It's more portable, simpler
> and takes advantage of all the C compiler optimizations. I'm not
> looking for Perl 6 to be a Java/Applet replacement. Is that really
> where we want to go?
>
While C is frequently used as a back-end for language implementations,
it is not necessarily the best choice. You might want to have a look
at http://www.cminusminus.org/abstracts/pal-ifl.html. This paper
describes the motivation behind the design of C--, a portable assembly
language that the functional programming guys at Harvard and Microsoft
Research are working on.
Some of the difficulties they had when using C as the back-end for
functional languages (like Haskell) were:
- C compilers are in charge of stack frame layout which means the
garbage collector might have a hard time figuring out which stack
locations contain live pointers.
- C compilers don't allow program control over low level aspects of
a program (e.g. registers, data and code alignment, and calling
conventions) which might need to be accessible to produce good
code for the language being compiled.
There are also other issues with using C as the only mechanism for
native code generation.
First there's binding time. There are number of Perl features for
which code can't be generated at compile time, e.g., eval and require.
How do we deal with these?
Second there's the issue of portability. Do folks distributing Perl
software have to generate binaries for every possible Perl target?
Or do they distribute a high performance binary for the target(s)
they have access to, and require everyone else to run a slower,
interpreted version of the same program?
While C might be fine and dandy for getting o.k. native code w/o too
much implementation effort, I think that it might be worth the effort
to implement a JIT compiler for the perl interpreter's intermediate
language. Just because Kaffe can't get decent performance with a JIT
compiler doesn't mean that we can't. Kaffe's open source JIT doesn't
represent the state of the art. Plus Perl != Java. Many of the
reasons for poor JIT performance in Java are related to specifics of
the Java language and its standard library (e.g. lots of
synchronization required for thread safety in the standard library
that the current crop of JITs can't safely remove.)
Just my $.02 worth.
-Kevin
--
Kevin Scott [EMAIL PROTECTED]
Ph.D. Student http://www.cs.virginia.edu/~jks6b
Department of Computer Science
University of Virginia
