The Java Virtual Machine
A Java program is the same, regardless of which CPU and OS it is intended to run on. This is true also for a compiled Java program, since that consists of platform independent JVM bytecode instructions.
The following is an excerpt from Oracle’s specification, describing what the JVM is:
“The Java virtual machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating system-independence, the small size of its compiled code, and its ability to protect users from malicious programs.
… Oracle’s current implementations emulate the Java virtual machine on mobile, desktop and server devices, but the Java virtual machine does not assume any particular implementation technology, host hardware, or host operating system. It is not inherently interpreted, but can just as well be implemented by compiling its instruction set to that of a silicon CPU. It may also be implemented in microcode or directly in silicon.”
Imsys JVM – not quite “virtual”
Imsys’ processor IM3000 is a CISC (Complex Instruction Set Computer), which means that its instruction set consists of many and varied instruction types, and the execution of the instructions is therefore controlled by internal microcode rather than by hard-wired logic circuitry, as is the case in simple microcontrollers and RISC processors (Reduced Instruction Set Computer). In the Imsys processor the JVM bytecodes have been microcoded and thus included in its native instruction set.
This means that the JVM bytecodes are executed locally inside the processor, by sequences of wide microinstructions with many degrees of freedom for the control of every cycle. This greatly reduces the number of cycles needed, and the energy consumed, when comparing with software interpretation of the bytecodes.
Imsys and C language programs
A compiled Java program is small – its semantic density is high, thanks to the short, efficiently encoded, JVM bytecode instructions that each describe actions that may require many cycles. The native instructions of a RISC processor, by comparison, are wider and cannot control more than one execution cycle each.
A program written in C and compiled for a RISC processor is therefore much larger than a program written in Java and compiled to JVM bytecode. This is not the case for the Imsys processor. C and Java statements are semantically similar and many of the JVM bytecode instructions are therefore just as usable for C, and Imsys’ C compiler uses them. This is the reason why C language programs typical for embedded systems take up less than 1/5 the memory space needed for the same programs when compiled for ARM (according to benchmarks from Texas Instruments). The higher code density also reduces the energy consumed by the fetching of instructions from memory.