Hardware Reference
In-Depth Information
have been implemented through microprogramming, as discussed in Chap. 1. Al-
though IJVM is small, it is a good starting point for describing the control and
sequencing of instructions.
Our microarchitecture will contain a microprogram (in ROM), whose job is to
fetch, decode, and execute IJVM instructions. We cannot use the Oracle JVM
interpreter because we need a tiny microprogram that drives the individual gates in
the actual hardware efficiently. In contrast, the Oracle JVM interpreter was written
in C for portability and cannot control the hardware at all.
Since the actual hardware used consists only of the basic components de-
scribed in Chap. 3, in theory, after fully understanding this chapter, the reader
should be able to go out and buy a large bag full of transistors and build this subset
of the JVM machine. Students who successfully accomplish this task will be given
extra credit (and a complete psychiatric examination).
As a convenient model for the design of the microarchitecture we can think of
it as a programming problem, where each instruction at the ISA level is a function
to be called by a master program. In this model, the master program is a simple,
endless loop that determines a function to be invoked, calls the function, then starts
over, very much like Fig. 2-3.
The microprogram has a set of variables, called the
state
of the computer,
which can be accessed by all the functions. Each function changes at least some of
the variables making up the state. For example, the Program Counter (PC) is part
of the state. It indicates the memory location containing the next function (i.e.,
ISA instruction) to be executed. During the execution of each instruction, the PC
is advanced to point to the next instruction to be executed.
IJVM instructions are short and sweet. Each instruction has a few fields, us-
ually one or two, each of which has some specific purpose. The first field of every
instruction is the
opcode
(short for
operation code
), which identifies the instruc-
tion, telling whether it is an
ADD
or a
BRANCH
, or something else. Many instruc-
tions have an additional field, which specifies the operand. For example, instruc-
tions that access a local variable need a field to tell
which
variable.
This model of execution, sometimes called the
fetch-decode-execute cycle
,is
useful in the abstract and may also be the basis for implementation for ISAs like
IJVM that have complex instructions. Below we will describe how it works, what
the microarchitecture looks like, and how it is controlled by the microinstructions,
each of which controls the data path for one cycle. Together, the list of micro-
instructions forms the microprogram, which we will present and discuss in detail.
The
data path
is that part of the CPU containing the ALU, its inputs, and its
outputs. The data path of our example microarchitecture is shown in Fig. 4-1.
While it has been carefully optimized for interpreting IJVM programs, it is fairly
similar to the data path used in most machines.
It contains a number of 32-bit
