[maemo-developers] Java acceleration/Jazelle

From: P. Durante shackan at gmail.com
Date: Wed Aug 15 17:23:14 EEST 2007
sorry for chiming in, incidentally I've just started to study the arm
architecture and the ARM1136J-S manual seems clear about a couple of

On 8/15/07, Simon Pickering <S.G.Pickering at bath.ac.uk> wrote:
> Thank you for the links, these are things I've not seen before.
> > So let me dump the stuff I turned up so far:
> >
> > URL: <http://www.scratchpost.org/patches/jazelle-disassembly.png>
> > Here you can see the size and alignment of the java instructions.
> > (the entire document is
> > <http://www.arm.com/pdfs/DUI0066D_ADS1_2_AXD_armsd.pdf>)
> Looking at the Memory Processor view in Jazelle state (fig 5-39 on page 5-33 of
> the pdf), the left-hand column showing the Address of the bytecodes indicates
> that bytecodes are byte-length (or variable length depending on their
> arguments), not 32bit as we were thinking. 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.
> The same thing is seen in the disassembler shown in Fig 5-52 on page 5-41.
> Section 6.5 on page 6-9 specifically states that Jazelle assembly instructions
> are 8-bit. So we can conclude that they are byte aligned rather than word
> aligned. I wonder why the word aligned code appeared to work?
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 Java state, all instruction fetches are in words.

> "The key to making this approach work lies in a single new ARM instruction, "BXJ
> Rm," for entering Java state. This instruction first performs a test on one of
> the condition codes. If the condition is met, it then stores the current program
> counter (PC), puts the processor into Java state, branches to the specified
> target address and begins executing Java byte codes."
> Performs a test on one of the condition codes.... Which one I wonder? Or is this
> where a Java flag is checked (I'll have to take another look in the chip manual
> pdf). Anyone have any thoughts?

Almost all ARM instructions can be optionally executed, that is, the 4
most significant bits of almost every ARM opcode include a condition
code, if the condition is met, the instruction is executed, otherwise
it is equivalent to a NOP,

Branch and exchange to Java state: BXJ{cond} <Rm>

if you don't specify a condition, the assembler assumes AL and the
branch is unconditionally executed, nothing fancier than that

some other possible values for {cond} are: EQ (Z=1), NE(Z=0), LT(N!=V), VS (V=1)

> My understanding is that condition codes are N(egative), Z(ero), C(arried over)
> and (o)V(erflow) and that the J bit, which is also in CPSR (and isn't a
> condition code afaik), is set by the BXJ instruction, rather than needing to be
> set before the BXJ instruction. In fact setting this bit is explicitly advised
> against wherever it's mentioned. Therefore do we need to do a CMP before the BXJ
> to get it to do something?

You can switch the operating state of the ARM1136JF-S processor
between ARM state and Java state using the BXJ instruction.

and also

MSR cannot be used to change the J bit in the CPSR.

so, you don't set it, the CPU does, it seems no other setup is
required, but I can't be sure about that

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

no suffix means BXJAL


More information about the maemo-developers mailing list