Java Reference
In-Depth Information
native code at the very start?" One reason is Java's dynamic quality means we are not
exactly sure which code will be needed at compile time. Further, new classes may be loaded
while a Java program is executing. That HotSpot compilation can compete with static
compilation in performance is counter-intuitive to programmers. But Oracle has bench-
marks that demonstrate that the HotSpot VM often out-performs programs that have been
statically compiled to native code.
6.1.2 What We Will Do Here, and Why
Here we shall translate a small subset of JVM instructions to the native code for the
MIPS architecture. MIPS is a relatively modern reduced instruction set computer (RISC),
which has a set of simple but fast instructions that operate on values in registers; for this
reason it is often referred to as a register-based architecture|it relies on loads and stores
for moving values between memory and its thirty-two general-purpose registers. The RISC
architecture differs from the traditional complex instruction set computer (CISC), which
has fewer but more complex (and so slower) instructions with a wider range of operand
addressing capabilities; CISC operands can be expressed as registers, memory locations, or
a combination of both (allowing indexing), and so CISC architectures normally have fewer
(for example, eight) general-purpose registers. A popular CISC architecture is Intel's family
of i86x computers.
More accurately, we will target the MIPS assembly language, which is directly inter-
preted by James Larus's SPIM simulator [Larus, 2010], and is readily available for many
environments. We call this assembly language SPIM code. (SPIM is MIPS spelled back-
ward.)
Assembly code is a symbolic language for expressing a native code program. It captures
the native code program nicely because there is a one-to-one correspondence between it and
the bit pattern representing each individual instruction but it is more meaningful to the
reader.
Normally, a compiler will produce this assembly code and then use an assembler, i.e., a
simple translator for translating the assembly code to the bit representation of native code.
But the SPIM interpreter interprets the MIPS assembly code directly. This serves our
purpose just fine; we can produce sequences of MIPS instructions that are both readable
and can be executed directly for testing the code we generate.
Our goal here is illustrated in Figure 6.1. The work that we have already done is shown
using the dashed line. The work we intend to do here in this chapter and the next is shown
using the solid line.
FIGURE 6.1 Our j-- to SPIM compiler.
Here we can re-define what constitutes the IR, the front end, and the back end:
JVM code is our new IR.
The j-- to JVM translator (discussed in Chapters 1{5) is our new front end.
The JVM-to-SPIM translator (discussed in this chapter and the next) is our new back
end.
Search WWH ::
Custom Search