Compilation - Introduction to Compiler Construction in a Java World - page 8

1.3.6 Compiling JVM Code to a Register Architecture
To remedy this deficiency, we (beginning in Chapter 6) discuss the compilation of JVM
code to code for the MIPS machine, which is a register-based architecture. In doing this, we
face the challenge of mapping possibly many variables to a limited number of fast registers.
One might ask, \Why don't we simply translate j-- programs to MIPS programs?" After
all, C language programs are always translated to native machine code.
The strategy of providing an intermediate virtual machine code representation for one's
programs has several advantages:
1. Byte code, such as JVM code or Microsoft's CLR code is quite compact. It takes up
less space to store (and less memory to execute) and it is more amenable to transport
over the Internet. This latter aspect of JVM code made Java applets possible and
accounts for much of Java's initial success.
2. Much effort has been invested in making interpreters like the JVM and the CLR run
quickly; their just-in-time compilers are highly optimized. One wanting a compiler
for any source language need only write a front-end compiler that targets the virtual
machine to take advantage of this optimization.
3. Implementers claim, and performance tests support, that hotspot interpreters, which
compile to native code only those portions of a program that execute frequently,
actually run faster than programs that have been fully translated to native code.
Caching behavior might account for this improved performance.
Indeed, the two most popular platforms (Oracle's Java platform and Microsoft's .NET
architecture) follow the strategy of targeting a virtual, stack-based, byte-code architecture
in the first instance, and employing either just-in-time compilation or HotSpot compilation
for implementing these \interpreters".
1.4 An Overview of thej--to JVM Compiler
Our source language, j--, is a proper subset of the Java programming language. It has about
half the syntax of Java; that is, its grammar that describes the syntax is about half the size
of that describing Java's syntax. But j-- is a non-trivial, object-oriented programming lan-
guage, supporting classes, methods, fields, message expressions, and a variety of statements,
expressions, and primitive types. j-- is more fully described in Appendix B.
Our j-- compiler is organized in an object-oriented fashion. To be honest, most compilers
are not organized in this way. Nor are they written in languages like Java, but in lower-level
languages such as C and C ++ (principally for better performance). As the previous section
suggests, most compilers are written in a procedural style. Compiler writers have generally
bucked the object-oriented organizational style and have relied on the more functional
organization described in Section 1.3.
Even so, we decided to structure our j-- compiler on object-oriented principles. We chose
Java as the implementation language because that is the language our students know best
and the one (or one like it) in which you will program when you graduate. Also, you are
likely to be programming in an object-oriented style.
It has many of the components of a traditional compiler, and its structure is not neces-
sarily novel. Nevertheless, it serves our purposes: