The G4 and the K7: an architectural look at two post-RISC processors
A hardware decoder is faster and more efficient than a microcode decoder.
To make hardware decoding feasible, the instruction set must be limited to a
small set of uniformly-sized instructions. This constraint is what makes
hardware decoding one of the hallmarks of a RISC CPU. The G4 has a large
set of uniformly-sized instructions, so it uses a hardware decoder to decode
them. Note that I said that the MPC7400's instruction set is
"large." This expanded instruction set is a post-RISC feature,
as the original RISC machines had a reduced number of instructions, as well as
instructions of reduced complexity. Most modern post-RISC machines like
the 7400 have added so many instructions that they have as many (or more)
instructions than any classic CISC machine. (Again, for more on this
issue, see my RISC
vs. CISC article). Nevertheless, the 7400's decoding scheme is fairly
simple, in spite of its expanded instruction set; the instructions are fetched
from the cache and decoded by a fast, efficient, hardware decoder. Too bad
the K7 doesn't have it this easy.
The K7's decoding scheme is much more complicated than the 7400's, because
the K7 has to deal with the vagaries of the aging and oft-maligned x86 ISA.
The K7 pays a steep price, in terms of transistor resources and clock cycles,
for x86 compatibility. First off, AMD added a predecode cache to help deal
with the variable lengths of the x86 instructions; this is extra cache space
that the G4 doesn't need. Furthermore, the K7 doesn't run the big,
unwieldy x86 instructions directly, but it decodes them into what AMD calls
MacroOps. Each MacroOp is composed of one or two smaller instructions: a
register-to-register instruction and a memory access instruction (LOAD, STORE,
or LOAD/STORE). These smaller instructions are just called ops, and a
single one of them is roughly equivalent to a P6 "rop", or to one of
the 7400's ordinary instructions. In this way, the K7 emulates the x86 ISA
using RISC-like instructions that correspond to regular instructions on a RISC
To do all of this hefty decoding work, the K7 uses two separate decoding
pipelines. It has a hardware decoder that decodes the smaller x86
instructions, and a microcode decoder that decodes the larger and more
complicated x86 instructions. Since the larger x86 instructions are rarely
used, the hardware decoder sees most of the action. Thus the microcode
decoder doesn't really slow the K7's front end down. All it does is eat up
transistor real estate, contributing the the K7's extremely high transistor
count, large die size, high power dissipation, etc.. Not only do all of
these wild decoding contortions jack up the transistor count, but they affect
the pipeline depth as well. The K7 spends three pipeline stages (or three
cycles) after the instruction fetch finding and positioning the variable-length
x86 instructions onto 6 decode positions (3 MacroOps = 6 ops). As a
result, the K7's pipeline is about 3 stages longer than it would be if the x86
ISA were not CISC.
The big question is, of course, how all of this x86 baggage effects the K7's
performance. Well, the answer isn't as simple as it might seem at first.
The key to the K7's performance lies in keeping those deep pipelines full at all
times, a feat that requires some special hardware: the Branch Prediction
Having a deep pipeline can actually be a Good Thing™ (you get higher clock
rates this way), but it does carry with it certain risks. Quite often the
processor's front end encounters a conditional construct, such as an
IF-THEN-ELSE statement, that can change the flow of the program depending on the
outcome of some comparison or calculation. Older processors had to wait
until this condition was evaluated to find out which branch to take, and while
they were waiting the pipeline stages downstream from the branch emptied out and
In the above picture, you can see the blue IF enter the pipeline. As it
sits there being evaluated the rest of the instructions downstream move on,
leaving behind empty pipeline stages. Contrast this to the second figure
below, where the Branch Prediction Unit correctly predicts that the THEN branch
will be taken, and starts executing that branch's instructions immediately while
the IF is being evaluated.
With branch prediction, the pipeline stays full and machine cycles don't go
to waste. The deeper the pipeline, the more important branch prediction
becomes in keeping it full.
You might notice that in the above figure, if the BPU mispredicts the branch
then those red THEN instructions would have to be flushed from the pipeline and
the yellow ELSE instructions started. The price of a mispredict is higher
the more stages you have, because you have to clear out and replace more
instructions when your prediction is wrong. Since the K7's pipeline is so
deep (10-15 stages), it can't afford to mispredict a branch. As a result,
AMD spent a lot of resources on the K7's Branch Prediction Unit (BPU).
Without going into too much detail on the intricacies of the K7's or 7400's
BPUs, it should suffice to say that K7's BPU has a lot more space in it and can
keep track of a much higher number of branches than the 7400's. The K7
uses that space to keep track of the histories of a large number of branch
instructions, so it can make the extremely accurate predictions that it
needs to keep its deep pipeline full. On the other hand, since the 7400's
pipeline is only 4 stages deep it doesn't pay as steep a price for mispredict.
Thus it needs less space for keeping track of all of those branch histories.