[maemo-developers] Java acceleration/Jazelle

[From: Danny Milosavljevic]

Hello,

On Wed, 15 Aug 2007 12:43:43 +0100, Simon Pickering wrote:

> Thank you for the links, these are things I've not seen before. 

No problem :-)

> bytecodes are byte-length (or variable length depending on their arguments), not 32bit as we were thinking. 

Yeah, the confusion arises because the CPU does a _prefetch_ - always fetching words - in Java mode. That doesn't mean the instruction is as big as a word, quite the opposite. Usually it will fetch 4 java instructions that way.

>This does assume that the Address
> column is showing the address in terms of bytes and not some other unit, but I
> think this is a fair assumption.

Yeah.

> Do my original R12 and R14 mappings mean anything I wonder (see last section of
> this email), or were they just random names for the patent?

I think they changed them afterwards... not sure, though.

> these values are not altered when the exception occurs. I've looked at this in
> passing and it doesn't seem to show anything (that I expected - see my previous
> long email to see for yourselves) in the registers after the exception handler
> has been run. 

Yeah, I think we ned to set up some more complicated vector table, see below.

> Obviously we ought to be setting the pointer to the Jazelle exception table (if
> we knew which register to put it in and what form it takes!), 

See below ;-)

> but do we also
> need to setup things like the Java stack pointer, pointer to variables area and
> constant pool pointer? Even if we don't need to actually initialise the data at
> these addresses, do we need to allocate some memory and then provide pointers?

Good question. I guess for testing it wouldn't hurt to use valid addresses for these until we get something running and then start ripping stuff out again?

> I created some test code for this:
> http://people.bath.ac.uk/enpsgp/nokia770/jazelle/jalimo6a.c

Cool, I'm pulling my hair out how to get the inline assembler to nicely align things (pad handler code to 32 bytes). Help? :)

> I don't know whether the BXJ instruction requires the condition code suffix, but
> it certainly compiles without complaint.

No, that's an ARM special feature where you can always have a condition on each instruction. If the condition did not hold, it would skip the instruction. I think this is so that branch prediction has an easier time (because for small things there will be no branch needed, the total number of branches will go down a lot).

> The output is:
> 
> Jalimo6a.bin
> ============
> 1: x/i $pc  0x841c <main+108>:  bxjne   r0
> (gdb) info registers
> r0             0xbef68640       -1091140032
> r1             0x8428   33832
> r2             0x8428   33832
> r3             0x8428   33832
> r4             0x8428   33832
> r5             0x8428   33832
> r6             0x8428   33832
> r7             0x8428   33832
> r8             0x8428   33832
> r9             0x8428   33832
> r10            0x8428   33832
> r11            0x8428   33832
> r12            0x8428   33832
> sp             0x8428   33832
> lr             0x8428   33832
> pc             0x841c   33820
> fps            0x1001000        16781312
> cpsr           0x20000010       536870928
> (gdb) si
> 
> Program received signal SIGILL, Illegal instruction.

I think it's disliking that the SW table is not set up.

> Do we need to set some bit to enable Jazelle?

No, the ARM people like to have special instructions to change processor modes, like "ENTERX" or "BXJ" or the like. (I think. :))

> All of the unused byte codes are handled as exceptions. 

Well not exactly normal exceptions, but there is a vector table with handler code, yes.

> One of the unused byte codes is used as the means to return to the calling program.

> This confirms Scott's idea. From the wording it looks like it's up to the handler software to actually perform the return operation, rather than the Jazelle hardware doing it itself.

Yeah...

> So we know(?) R14 is the bytecode PC.

Some say it's R15. Well, we don't need to touch it manually yet...

Anyway, new info from
<http://www.cpe.ku.ac.th/~pom/courses/204521/report/2001/Jazelle.ppt> integrated:

R0..R3   cache java expression stack
R4       local variable 0 ("this" pointer) (montioned in 2 different sources)
R5       pointer to table of SW handlers
R6       Java stack pointer (mentioned in 2 different sources)
R7       Java variables pointer
R8       Java constant pool pointer
R9..R11  reserved for JVM (hardware doesn't use them)
R12,R14  sometimes Java return address for some instructions. Some say Java PC is in R14.
R13      Machine stack pointer (not Java)
R14      interrupt handler saves PC here (although doesn't it do that in the shadow register?)
R15      Java PC


R5 is maybe a table that can be used by Thumb-EE, which would be (got this from some ARM manual on their web site, I think):

>Handlers: HB{L} #handler
>A new 16-bit instruction, which performs a branch, with optional link, to one of 256 ‘handler routines’, specified by the value of #handler. Execution continues from an address given by  "HandlerBase + 32*handler" with a return address optionally stored in R14

>A handler routine will contain a commonly used sequence, often corresponding to a complex bytecode; for example, Java bytecodes such as idiv, fadd, lmul, athrow, and many more. Other uses include implementing a call to a profiling routine, or calling a thread switch routine for a VM that implements co-operative threading

>Handlers: HB{L}P #param,#handler
>This instruction is a variant on HB{L}, and allows a small integer parameter be passed to a handler. There are some restrictions in usage – you can only call the first 32 handlers with HB{L}P. HBLP allows a parameter in the range 0 to 31, while HBP allows a parameter in the range 0 to 7.
>The parameter is copied into R8 for the handler routine to use, and so does not corrupt the general-purpose low registers R0 to R7 available to a JIT/DAC. 
>This branch instruction variant can call routines that require a parameter that is known at compile time – e.g. the bytecode newarray <type>. The instruction can also be used for bytecodes that require an index into the constant pool, e.g. new [Ed. note: "new array" ?].

>HandlerBase is a coprocessor register configured by each individual VM, and is    
context switched by the OS.

> null pointer exception handler, at address HandlerBase-4.

> The new processor state, ‘Thumb-EE’, is entered and exited with the new ENTERX and LEAVEX instructions. New instructions (among others): HB{L}P, HB{L}

> The HBL and HBLP instructions act as function calls and push the return address onto the return stack.

So what we want is maybe (even probably) a SW table like:

("off_dec" offset in decimal)

off_dec instruction
-4      B    null_pointer_handler
 0      handle the instruction somehow
        return
32      handle another instruction somehow
        return
64      handle another instruction somehow
        return
......
???     bail out of Java mode for good and return. How exactly? Just "B" somewhere? Just return?

I have no idea how the instruction opcode and the handler index are related, so take this with a grain of salt.

And I need help with the gcc inline assembler. I haven't exactly used it in the last few years :)

what I want to do is something like:

int table[] = asm volatile("
                ".offset 0"
                "B  null_pointer_handler"
                ".offset 4"
                "do something"
                ".offset 36" // pads until this offset is reached, or errs out.
                "do something"
                ....
                (a total of 256 entries of ".offset ...", "do something")
                ".label null_pointer_handler"
                "do something"
            ");

R5 = table + 1; // move offset by 4 to satisfy R5 requirement (of "HandlerBase - 4" being valid).

If you know what I'm getting at :)

cheers, 
   Danny