MicroJava chip set emerges, bit by bit
Embedded Systems
Harlan McGhan, Technical Marketing Manager, Volume Products Group,
ÿ
01/12/98
Electronic Engineering Times
Page 96
Copyright 1998 CMP Publications Inc.
ÿ
Sun Microelectronics, Mountain View, Calif.#
What makes Java technology more than just another new and better object-oriented programming language is that Java is a write-once, run-anywhere programming platform, implemented via the Java Virtual Machine. The JVM is a complete, highly portable execution environment for Java programs, that can be added on top of any combination of CPU and operating system. When implemented in full compliance with its specification, the JVM guarantees that the same Java program will generate-bit-for-bit-the identical results in all cases, regardless of the underlying CPU-OS combination.
The JVM, then, is a software abstraction layer that both generalizes and conceals all specifics of the underlying CPU and OS. The benefit is that a single image of a program will run anywhere the virtual machine is available, eliminating the need to write and maintain different versions of the same program for different platforms.
But there is a price to be paid for these advantages. Specifically, programs no longer have any immediate contact with the underlying hardware that ultimately runs them, but must execute indirectly through a translation mechanism built into the JVM. The JVM first verifies the byte-code program, and then translates the universal safe byte-code instructions into machine-specific binary instructions understood by the underlying CPU.
In principle, there are only three possible responses to the burden of indirect execution imposed by Java technology. The most direct response is simply to accept this burden and manage it as necessary. Which is to say that, although software translation mechanisms impose an overhead burden on code execution, the nature of this burden is not fixed. Where ample execution time is available (because, for example, programs are I/O bound), interpreters offer a simple and reliable way to run Java programs. Alternatively, where ample machine resources are available (for example, a large memory subsystem of 32 Mbytes or more), just-in-time compilers hold out the promise of execution speeds rivaling, and in some cases even exceeding, the performance of traditional statically compiled programs.
Limited resources
As software translation techniques approach their limits of effectiveness-as both available execution time grows shorter and available machine resources become more limited-two alternative "reductive" execution strategies for Java programs can be considered.
The first alternative is direct compilation, eliminating the byte-code intermediate program format. Where the need to maximize execution efficiency is paramount, programs written in the Java programming language can be directly compiled to platform-specific machine binaries, just like any other high-level language. But since this solution sacrifices the two principal virtues of Java -platform independence and the strong Java security model-it is of limited value, meriting consideration only where neither of these issues carries any weight.
For many segments of the market, particularly in the embedded world, the best solution is a second alternative, direct execution, thus eliminating the translation of byte-code programs. This is a much more palatable reduction in the execution chain for Java programs, keeping the byte-code program format, preserving all the associated virtues of platform independence and program security, but eliminating the need to transform this format for execution purposes.
But implementing this alternative requires a new CPU architecture, conceived in the post- Java era, and explicitly designed to read and execute Java byte-code instructions directly in hardware.
This is precisely the goal of and motivation behind Sun's JavaChips architecture, first with the original picoJava core architecture and now with the new microJava chip set.
The initial implementations of this architecture accomplished what previously was not possible-they simultaneously maximize the efficiency (minimize the overhead) of executing a Java program, while preserving all the benefits of platform independence and run-time security associated with the byte-code program format.
But as originally implemented, the JavaChip had a very important limitation because it is a new CPU architecture. Though JavaChips are not limited to executing Java code, it is what they do best. If there is non- Java code written in any other high-level language, for best performance it is necessary to use a compiler to convert these programs into Java code recompiled specifically for their target JavaChip. This becomes more burdensome in direct proportion to the amount of legacy (non- Java ) code the system must run.
The latest JavaChip implementation, the microJava family, was developed to deal with this. First is the microJava 701, designed to run non- Java code about as efficiently as comparable RISC-CPU architectures. While it offers no tangible price/performance advantage when executing non- Java code, as a JavaChip it executes Java byte code faster than the alternative, which is to use a general-purpose chip optimized for other high-level languages.
The 701 is designed to be a CPU, facilitating creation of inexpensive "thin-client" machines of all types. This means it makes possible complete systems designed in minimal time and built for minimal cost. In this respect, microJava 701 closely resembles SME's current system-on-a-chip microSparc CPUs: hook up a memory subsystem and an I/O subsystem to the controllers integrated on-chip, and you're ready to do useful work.
Even as the 701 attempts to minimize system-level cost by building the core-logic chip set into the CPU itself, it tries to preserve enough design flexibility to fit readily into a range of possible applications falling within its price/performance budget.
To meet this goal, it integrates only those basic functions any type of system needs. And even there, it tries to preserve choice wherever possible. |
