Hi, 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 things
On 8/15/07, Simon Pickering <[EMAIL PROTECTED]> 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? > > [quote] 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. [/quote] > "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, [quote] Branch and exchange to Java state: BXJ{cond} <Rm> [/quote] 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? > [quote] You can switch the operating state of the ARM1136JF-S processor between ARM state and Java state using the BXJ instruction. [/quote] and also [quote] MSR cannot be used to change the J bit in the CPSR. [/quote] 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 regards, Paolo _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
