THE MICROARCHITECTURE LEVEL - Structured Computer Organization - page 280

sequence for ISTORE after the first two instructions, so wide istore4 branches to
istore3 .
Our next example is a LDC W instruction. This opcode is different from ILOAD
in two ways. First, it has a 16-bit unsigned offset (like the wide version of ILOAD ).
Second, it is indexed off CPP rather than LV , since its function is to read from the
constant pool rather than the local variable frame. (Actually, there is a short form
of LDC W ( LDC ), but we did not include it in IJVM, since the long form incorpor-
ates all possible variations of the short form, but takes 3 bytes instead of 2.)
The IINC instruction is the only IJVM instruction other than ISTORE that can
modify a local variable. It does so by including two operands, each 1 byte long, as
shown in Fig. 4-21.

IINC
(0x84)

INDEX CONST

Figure 4-21. The IINC instruction has two different operand fields.

The IINC instruction uses INDEX to specify the offset from the beginning of the
local variable frame. It reads that variable, incrementing it by CONST , a value con-
tained in the instruction, and stores it back in the same location. Note that this in-
struction can increment by a negative amount, that is, CONST is a signed 8-bit con-
stant, in the range 128 to +127. The full JVM includes a wide version of IINC

where each operand is 2 bytes long.
We now come to the first IJVM branch instruction: GOTO . The sole function
of this instruction is to change the value of PC , so that the next IJVM instruction
executed is the one at the address computed by adding the (signed) 16-bit offset to
the address of the branch opcode. A complication here is that the offset is relative
to the value that PC had at the start of the instruction decoding, not the value it has
after the 2 offset bytes have been fetched.
To make this point clear, in Fig. 4-22(a) we see the situation at the start of
Main1 . The opcode is already in MBR ,but PC has not yet been incremented. In
Fig. 4-22(b) we see the situation at the start of goto1 .Bynow PC has been incre-
mented but the first offset byte has not yet been fetched into MBR . One micro-
instruction later we have Fig. 4-22(c), in which the old PC , which points to the op-
code, has been saved in OPC and the first offset byte is in MBR . This value is need-
ed because the offset of the IJVM GOTO instruction is relative to it, not to the cur-
rent value of PC . In fact, this is the reason we needed the OPC register in the first
place.
The microinstruction at goto2 starts the fetch of the second offset byte, leading
to Fig. 4-22(d) at the start of goto3 . After the first offset byte has been shifted left
8 bits and copied to H , we arrive at goto4 and Fig. 4-22(e). Now we have the first
offset byte shifted left in H , the second offset byte in MBR , and the base in OPC .By
constructing the full 16-bit offset in H and then adding it to the base, we get the

−