JVM Backend for GCC [Was: gcc backend that can be...]

[Adam Megacz <adam at xwt dot org>]

> http://gcc.gnu.org/ml/java/1999-q2/msg00006.html

I think the key here is that the backend shouldn't try to maintain any
correlation at all between JVM objects/classes/methods and input
language datum/classes/methods.  While this analogy is great for
things like CNI, I actually think it's a mental obstacle when you're
trying to create a bytecode backend.


> "Gcc does assume it can do pointer arithmetic.  In Java bytecodes,
> you can't, at least not in the same way.

But Java can do arithmetic on ints, which are used as indexes into a
huge int[] containing all the data used at runtime.  True, this is not
the best way to store your data, but the slowdown is constant-factor
and (I suspect) less than 2.

After looking over the MIPS architecture, I actually think it's
*perfect* for this.  I can map the MIPS instructions very cleanly onto
Java array load/stores (MIPS does not allow nonaligned memory access).
MIPS registers get mapped to 32 stack variables.  The instruction set
is absolutely minimalist.  Instructions map to case blocks in a huge
switch:

public static void main(String[] s) {
    final int[] memory = new int[HOWMUCHRAMYOUNEED];
    int pc = 0;
    int register1;
    int register2;
    int register3;
    // ...

    while(true)
        switch(pc) {
            // ...
            case 0x00000010:
                register1 = memory[register2 + 4];     // LOAD r1, [r2 + 4]
                pc += 4;
            case 0x00000014:
                pc = register3;                        // JMP r3
                continue;
            // ...

Turning off bounds checking somehow would give you reasonably fast
code considering the hoops you've jumped through.  If you have
segments that compile to more than 64k of Java bytecode, you'll need a
trampoline that saves registers to get between them.

  - a