Hardware Reference
In-Depth Information
with the Goto bit on and still has ample room left in the queue, the queueing unit
then sends an acknowledgement signal back to the decoding unit. When the de-
coding unit sees the acknowledgement, it sends the index of the next IJVM instruc-
tion to the queueing unit.
In this way, the sequence of IJVM instructions in memory are ultimately con-
verted into a sequence of micro-operations in a queue. These micro-operations
feed the
MIR
s, which send the signals out to control the data path. However, anoth-
er factor we now have to consider is that the fields on each micro-operation are not
active at the same time. The
A
and
B
fields are active during the first cycle, the
ALU
field is active during the second cycle, the
C
field is active during the third cycle,
and any memory operations take place in the fourth cycle.
To make this work properly, we have introduced four independent
MIR
s into
Fig. 4-35. At the start of each clock cycle (the
w
time in Fig. 4-3),
MIR3
is copied
to
MIR4
,
MIR2
is copied to
MIR3
,
MIR1
is copied to
MIR2
, and
MIR1
is loaded with a
fresh micro-operation from the micro-operation queue. Then each
MIR
puts out its
control signals, but only some of them are used. The
A
and
B
fields from
MIR1
are
used to select the registers that drive the A and B latches, but the
ALU
field in
MIR1
is not used and is not connected to anything else in the data path.
One clock cycle later, this micro-operation has moved on to
MIR2
and the regis-
ters that it selected are now safely sitting in the A and B latches waiting for the
adventures to come. Its
ALU
field is now used to drive the ALU. In the next cycle,
its
C
field will write the results back into the registers. After that, it will move on
to
MIR4
and initiate any memory operations needed using the now-loaded
MAR
(and
MDR
, for a write).
One last aspect of the Mic-4 needs some discussion now: microbranches.
Some IJVM instructions, such as
IFLT
, need to conditionally branch based on, say,
the
N
bit. When a microbranch occurs, the pipeline cannot continue. To deal with
that, we have added the Goto bit to the micro-operation. When the queueing unit
hits a micro-operation with this bit set while copying it to the queue, it realizes that
there is trouble ahead and refrains from sending an acknowledgement to the decod-
ing unit. As a result, the machine will stall at this point until the microbranch has
been resolved.
Conceivably, some IJVM instructions beyond the branch have already been fed
into the decoding unit (but not into the queueing unit), since it does not send back
an acknowledge (i.e., continue) signal when it hits a micro-operation with the Goto
bit on. Special hardware and mechanisms are needed to clean up the mess and get
back on track, but they are beyond the scope of this topic. When Edsger Dijkstra
wrote his famous letter ''GOTO Statement Considered Harmful'' (Dijkstra, 1968a),
he had no idea how right he was.
We have come a long way since the Mic-1. The Mic-1 was a very simple piece
of hardware, with nearly all the control done in software. The Mic-4 is a highly
pipelined design, with seven stages and far more complex hardware. The pipeline
is shown schematically in Fig. 4-36, with the circled numbers keyed back to the
Δ