Three companies have taken different approaches to direct Java bytecode execution. Two of them have developed dedicated Java processors. The third has a coprocessor design that can be embedded as part of a standard processor core, such as a MIPS core.
Compared to an interpreted Java virtual machine (JVM), direct Java bytecode execution improves performance. But that's not the only reason designers are going with an embedded Java processor or coprocessor. These devices boast real-time threading and low-power operation as well.
The first processor, Cjip, is dynamically reconfigurable. Designed by Uplands Vasby of Sweden's Imsys AB, it executes Java bytecodes, a register-based assembler, a stack-based assembler, and Forth. The Java support is a subset of the full Java 2 language, Java 2 Micro Edition (J2ME). Cjip also comes with its own real-time operating system (RTOS).
Cjip's reconfigurable nature lets designers add real-time extensions. Only two-thirds of the Cjip microcode is fixed. The JVM is implemented in microcode. Java thread scheduling and garbage collection are implemented as processes.
Veripherals, or virtual peripherals, are made available through microcode and 40 reconfigurable I/O pins. Existing veripherals include watchdog timers, sound generators, display interfaces, keyboard and touchscreen inputs, multimedia codecs, and TCP/IP stacks. They also can provide DSP capabilities.
The rest of Cjip is fairly conventional. Packaged in a 144-pin TQFP, it has an IEEE-754 floating-point math unit, interrupt support, and a four-channel DMA. Its integrated DRAM interface supports up to 128 Mbytes. The company's conservative 0.35-µm development process limits the maximum power consumption to 165 mW.
Like Cjip, the aJ-100 is a single-chip, J2ME-compatible Java processor—but that's where the similarity ends. Built by Ajile Systems, San Jose, Calif., the aJ-100 is strictly a 32-bit Java processor with patented multiple JVM technology that provides a significant security advantage when running third-party Java applets. Each virtual JVM executes in its own memory space and employs its own threading and memory utilization policies.
The aJ-100 implements two independent JVMs. One manages resident Java applications. The other handles downloaded applications. Its hardware-based threading support can switch between threads in less than 1 µs, eliminating the need for a resident RTOS. The Real-Time Extension to the Java Platform API is supported in hardware.
This processor also has 32 kbytes of on-chip SRAM for data memory and 16 kbytes for a microcode control store (Fig. 1). Its integrated memory controller supports ROM, flash memory, or SRAM using an 8-, 16-, or 32-bit interface. As a system-on-a-chip (SoC), the aJ-100 includes IEEE-754 floating-point support, a serial peripheral interface (SPI), and three 16-bit counter/timers. Five 8-bit, general-purpose ports and two 16550-compatible UARTs round out the on-board peripheral support. JTAG support is included as well.
Applications Control Power
The aJ-100 is housed in a 176-pin TQFP. Integrated power management supports normal, sleep, and standby modes. Power to individual peripherals is under application control. Designed through a 0.25-µm process, the aJ-100 is fully static with a maximum clock rate of 100 MHz. It consumes less than 1 mW/MHz.
The third processor, JStar, is built by JEDI Technologies of Santa Clara, Calif. This Java MIPS coprocessor can be integrated with almost any 32- or 64-bit processor core. It sits between the processor core and the processor's instruction and data caches (Fig. 2). Essentially, it serves as a hardware JVM when Java code is executed.
JStar acts as a pass-through when the core processor's native instructions are being executed. It also recognizes when Java code is being executed. At this point, JStar translates the Java instructions into core-processor native instructions that are passed to the core processor. The device switches back to the pass-through mode when the Java program stream ends.
The switch from native code to Java code is implemented as a special instruction that effectively replaces the call to a software JVM. Likewise, JStar knows that a return from the outermost Java call then returns to the caller that was running native code.
This processor handles transitions when a Java application calls a native mode routine. Similar transitions can occur when Java bytecodes aren't translated by JStar. This happens when a Java floating-point opcode is executed on a system where the core processor doesn't have floating-point support and floating-point operations are handled in software.
Not all JVMs are created equal, though. JStar can be configured to match four software JVM implementations; Sun's JVM and KVM, Transvirtual's Kaffe, and HP's Chai. Additional JVMs may be supported in the future, as it takes a couple of months to add this support.
The coprocessor approach's advantages are significant. Native-processor support is maintained, while the Java support takes advantage of the native processor's register files and arithmetic units. JStar operates at the core processor's speed, so increasing the clock rate improves both native and Java execution performance.
The processor takes on some Java chores itself, too. Most core processors are word-oriented. Java, however, is byte-oriented. JStar maintains the Java instruction pointer and fetches Java bytecodes directly from memory. Only word-oriented instructions are forwarded to the core processor.
JStar performs much better than Java interpreters, but just-in-time (JIT) Java compilers often have an edge. They can apply conventional compiler optimizations across multiple instructions. JStar simply translates, so it cannot perform compiler optimizations such as dead-code elimination and loop unrolling.
JIT compilers can actually provide better performance than JStar. Unfortunately, they require large amounts of memory—often more than half a megabyte. They also impose a significant amount of upfront overhead that can impact real-time applications.
JStar reduces the JVM's size, but it doesn't eliminate it. It handles bytecode fetch, decode, and execution, yet this is only part of what a JVM does. The processor doesn't improve the performance of garbage collection, thread synchronization, exception handling, and other Java chores. These tasks often make up a significant portion of a Java application's execution time.
JStar works best in embedded environments where memory and power are at a premium. It may not be the best choice when memory capacity is large and power consumption is not a major issue. Additionally, it consumes only about 30,000 gates, making it relatively small compared to the core processor. Its microcode is loaded in SRAM, enabling field updates.
Cjip costs $19 and the aJ-100 costs less than $20, both in large quantities. JStar's licensing costs are negotiable.
For more information about these processors, visit the three companies at www.imsys.se, www.ajile.com, and www.jeditech.com.