Hi, great to see someone tinkering with jazelle.
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>) <http://209.85.129.104/search?q=cache:eT7UO_bq1XIJ:www.commsdesign.com/design_corner/showArticle.jhtml%3FarticleID%3D16503207+arm+bxj&hl=en&ct=clnk&cd=4&client=firefox-a>: Once in Java state, the ARM PC is extended to 32 bits to address Java byte code. Byte codes are fetched and decoded in two stages (compared with a single decode stage when in ARM Thumb instruction-set state). A new Current Processor Status Register (CPSR) bit records the processor state. This is an important feature, as the CPSR is automatically saved and restored when handling interrupts and exceptions, so Jazelle technology is compatible with the existing ARM interrupt/exception model used by operating systems. [Further investigation shows this new register format to be called JPSR "A typical display of a Jazelle Program Status Register might show nZCvqIFtJSVC, giving information about: • 5 condition code flags (NZCVQ) • 2 interrupt enable flags (IF) • 2 state indicators (TJ) • 1 processor mode name (SVC)." (so it seems they cut the mode to 3 bits and added a "J" bit, I would have expected it in "x – the extension field PSR[15:8]", but no) ] In Java state, the processor assigns several ARM registers to functions specific to the Java machine (for example, R6 = stack pointer, R0-R3 = top elements of stack, R4 = local variable 0). This hardware reuse contributes to the small size of the additional logic (12,000 gates) required to implement the Java machine, and keeps all of the states required by the Jazelle extension in ARM registers, In addition, it ensures compatibility with existing operating systems, interrupt handlers and exception code. Keeping the top four elements of the stack in ARM registers [...]. The extension we've added divides Java byte codes into three classes: directly executed, emulated and undefined. The majority of the Java byte codes (138 on the ARM926EJ-S microprocessor core) are executed directly in hardware; the remainder are emulated by short sequences of highly optimized ARM instructions. -------------- <http://www.elecdesign.com/Articles/Index.cfm?ArticleID=4841&pg=2>: For efficiency, ARM keeps one of the local variables at zero in one of the ARM registers. Java applications frequently use the local variable at zero as a pointer to data. By keeping it in a register rather than in memory, the processor can perform better. Additionally, ARM uses other registers for other pointers. A pointer to the exception table holds the instruction sequences for the instructions that are not executed directly. Also, there is a pointer to the Java stack, a pointer to the Java variables area, and a pointer to the constant pool. Java programs access these groups of data all the time and keep them in existing ARM registers. -------------- + /* V5J instruction. */ + {0x012fff20, 0x0ffffff0, "bxj%c\t%0-3r"}, -------------- I hope this wasn't too useless, but I just wanted to post this before I forget it again (I can already feel it all vanish :-)) cheers, Danny _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
