Custom processors rev Java execution

When programming in C, stacks are normally maintained in main memory and data is pushed or popped between the stack and the CPU registers.

In standard software implementations of a Java Virtual Machine, or JVM, both Java stacks are also maintained in main memory. But many more memory transactions are required because data must be pushed and popped between the variable stack and the operand stack, and again between the operand stack and the CPU registers. It is clear that this adds further memory traffic and could severely hamper system performance. Stack op erations are an example of tasks that dedicated Javaxc processors do very well, but where RISC processors are inefficient.

Also, translating Java byte codes into native machine language of a processor must be done efficiently to reduce the size of the resulting native code and to reduce the complexity of the JIT. This is seen as a significant challenge because RISC and Java processor architectures and Java processor architectures are vastly different. The fact that some Java byte codes are complex and relate to many RISC instructions only serves to exaggerate performance loss.

Two routes have come to light that address the inefficiencies and challenges that developers face in accelerating Java execution in embedded systems.

Preprocessing concerns
The first approach attacks the translation problem. Some vendors have decided that an additional stage preceding the processor's instruction fetch can translate byte codes into RISC instructions as they arrive. This approach resem bles a coprocessor. However, because it precedes the processor and does not hoard bandwidth on the bus, it does not hamper system performance as much as a coprocessor.

Indeed, it could be called a Java preprocessor. Since the hardware translation block replaces the software translation in the JVM, Java performance is improved. Developers can expect between 5 and 6 CaffeineMarks/MHz from a technique such as this one.

Although performance is enhanced and the cost of the solution at approximately 12k gates may sound appealing, there are hidden drawbacks in implementing a hardware translation mechanism. Complex Java byte codes are normally translated in schemes like these by trapping the incoming byte code and executing a routine, written in the native machine language of the RISC processor.

The dynamic translation itself requires on-chip memory, similar to microprogrammed ROMs in CISC processors. This ROM can be quite large, so the 12k-gates measurement may give a deceptive view of act ual silicon area usage. In addition, the processor must switch from translating byte codes to running a RISC function.

A more efficient, highly integrated implementation can be realized if a processor architecture that has been designed for extension is used. Processors like these allow designers to add custom logic to the processor core architecture, such as new CPU instructions, supplementary CPU registers and control registers.

This is the approach that we have taken, by extending the CPU register file of the ARC tangent-A4 user-customizable processor and developing a twofold algorithm leveraging the hardware enhancements to create a high-performance RISC/Java processor at little cost.