Re: translate Java VM bytecode to native code using GCC backends ?

bothner@cygnus.com (Per Bothner) writes:


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


You might have already surveyed, but just in case...


The following paper discusses the translation of Java bytecode into
machine language, which uses a technique similar to yours.


"Java Intermediate Bytecodes", James Gosling, in Proceedings of ACM
SIGPLAN Workshop on Intermediate Representations (IR '95) (also
available as SIGPLAN Notices Vol.30, No.3, March 1995)


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


According to the paper, Java bytecode is designed so that it has the
following properties:


"... at any point in the program each slot in the stack and each local
variable has a type."
and
"When there are two execution paths into the same point, they must
arrive there with exactly the same type state."


So a translator can simply map each slot of Java VM stack into machine
register, without worrying (much) about branches. The paper describes
slightly more sophisticated translation technique, which uses
reference count to avoid unnecessary copying. (If you use gcc as
backend then such an optimization may not be necessary, though; gcc
optimizer should handle this as part of copy propagation).


Simon Peyton Jones' book:
        "The Implemenation of Functional Programming Languages",
        Prentice-Hall, 1987
describes similar technique for translating pseudo machine code
(G-code) into real machine code (VAX-11).


"Stack Caching for Interpreters", M. A. Etrl, Proc. SIGPLAN PLDI 95
may also be interesting. This paper describes how to map stack slots
to machine registers in *interpreters*.


Regards,
--mad


--

Return to the comp.compilers page.
Search the comp.compilers archives again.