[maemo-developers] Java acceleration/Jazelle

[From: Simon Pickering]

>>> Did you make a typo in your declaration (on p34) of int code[]? Should
>>> this not be unsigned char code[] as bytecodes are 1x byte not n x byte
>>> long (I'm assuming you're running on a machine with sizeof(int)>1)?
>> This is not a typo. I don't understand the reason, but it had only
>> worked with the integer array, not with bytes - don't know why.
>
> reasoning a minute, it sounds logical to me to have an int array,
> since normal arm instructions are 32bit long.
> So stretching the byte code to 4byte, the instructions and pc can
> internaly be handled as in normal arm operation mode.

Yes it does sound logical, but surely this would require more fiddling 
about when loading the bytecode into memory, or at least an 
intermediate step to split up the bytecodes. I don't know.

Relating to this (all page/section numbers refer to the ARM1136JF-S™ 
and ARM1136J-S Technical Reference Manual available from 
http://www.arm.com/pdfs/DDI0211I_arm1136_r1p3_trm.pdf):

p95.
"2.2 Processor operating states
The ARM1136JF-S processor has three operating states:
ARM state 32-bit, word-aligned ARM instructions are executed in this state.
Thumb state 16-bit, halfword-aligned Thumb instructions.
Java state Variable length, byte-aligned Java instructions.
In Thumb state, the Program Counter (PC) uses bit 1 to select between 
alternate
halfwords. In Java state, all instruction fetches are in words."

So we can see from this that the instructions are byte aligned and that 
fetches are performed in words (i.e. 32bits). But does this indicate 
that instructions should be in 8bit bytes? I have the feeling it's 
saying that 32bit's worth of data are fetched at a time (because this 
is the fastest way to do it), but that the instructions are actually 
8bit.

Quoted from your other email:
> This is not a typo. I don't understand the reason, but it had only
> worked with the integer array, not with bytes - don't know why.

The code you use:
int code[] = {0x10, //bipush
0x00, 0x00, 0x00, 0x2a, // dummy int: 42
0x3B, // istore_0
0x1A, // iload_0
0xB1, // return
0x00, 0x00, 0x00, 0x00, 0x00 // any rubbish

I've only thought about this quickly (and my apologoes if my 
littleendian conversion is wrong). If interpreted as bytes, I think 
this would actually still be valid code:

The first int would turn into {0x10, 0x00, 0x00, 0x00}, and adding on 
an extra byte from the second int would produce the same effect as your 
first instruction, but pushing 0x00 rather than 0x2a. A bytecode of 
0x00 is NOP iirc, 0x2a pushes a register onto the stack, etc. So it 
might just work when interpreted as bytes and manage to run all the way 
though. Just a guess though.

There are some other interesting points in the pdf:

On p128 (section 2.11.3 Exception entry and exit summary) there's a 
table telling us what happens to the registers and what return 
instruction to use for various exceptions when in ARM, Thumb or Java 
state. The interesting point is that the table says that SWI and UNDEF 
exceptions are not used in Java state. So this confirms that the 
unknown bytecode handler is not related to the usual undefined 
instruction handler as used in ARM mode.

The document also tells us about the bits in the CPSR and how to read 
them, and the bits in the CP14 register and how to read/write them. So 
I'll test this and see whether a bit needs to be set before invoking 
bxj.

Cheers,


Simon