|translate Java VM bytecode to native code using GCC backends ? email@example.com (Pascal.Girard) (1996-02-09)|
|Re: translate Java VM bytecode to native code using GCC backends ? firstname.lastname@example.org (1996-02-13)|
|Re: translate Java VM bytecode to native code using GCC backends ? email@example.com (MAEDA Atusi) (1996-02-19)|
|Re: translate Java VM bytecode to native code using GCC backends ? firstname.lastname@example.org (Per Bothner) (1996-02-19)|
|From:||email@example.com (Per Bothner)|
|Date:||13 Feb 1996 00:34:08 -0500|
|Organization:||Cygnus Support, Mountain View, CA|
|Keywords:||interpreter, GCC, Java|
Pascal.Girard <firstname.lastname@example.org> wrote:
>I have curiosity about the possibility of using parts of GNU GCC to
>achieve that compilation, thanks to a translator from ".class" format
>to the internal form of GCC (the RTL), and then reuse of the backends.
Yes, this is quite reasonable. In fact, I have started working on it.
(Cygnus does not have any funding for Java yet, so my efforts are
limited by the time I have available after working on other projects.
However, things are coming along nicely.)
>- The required work for the translator JBC->RTL should be simpler than
>a full compiler, and is architecture independant.
Mostly. On the other hand, we have lost useful information about
program structure. Also, the Java stack model may cause some
problems. We prefer not to have a Java stack at run-time, because it
does not match either gcc or typical architectures. Instead, the plan
is to keep a compile-time stack of expressions ("tree") nodes
corresponding to the current stack stack. A binary operation is
implemented by popping (at compile-time) two tree nodes off the stack,
and popping a tree-node corresponding to the result.
The obvious problem is dealing with branches. That is no problem if
the stack is empty at a branch; things get more complicated if the
stack can be non-empty. I have not yet analysed the problem.
>- except the interpreter, the run-time of Java VM (threads, GC, native
>libs, loader, ...) must be included : could it be borrowed from the
>available JVM implemantations ?
It is desirable to have a free and portable JVM implementation (and
people are working on that), but one can use Sun's for now.
>- the BC compiler should act within the Java "real" machine, after
>security checks on the bytecode : this implies a mix of Java and GCC
I have no idea what this means. If you mean that the compiled classes
should be binary compatible with the existing VM, then, yes, that is
desirable. (It is essential until there is a free VM.)
Cygnus Support email@example.com
Return to the
Search the comp.compilers archives again.