RISC vs. CISC Still Matters

Pages: 1 2 3 4 5 6

The last few years have not been kind to the leading high-end RISC processor architectures like MIPS, PA-RISC, SPARC, Alpha, and POWER/PowerPC. While low-end embedded RISC microprocessors were making huge headway in displacing the 680×0 family on the basis of high performance, low power, and compact die size, their larger, more complex, and lower volume brethren were under continuous attack in the low-end server and workstation market by x86 CISC processors. Today, 0.18 um x86 processors from two different vendors are yielding integer performance levels neck and neck with the fastest RISC processor, the Alpha EV67, and well ahead of all other RISC designs.

At the same time Intel is reaping the benefit of a long-term effort at convincing the marketplace that the difference between RISC and CISC processors was somehow shrinking. This first started when Intel released its i486 processor, and it was widely reported as having a “RISC integer unit”. Despite the utter meaninglessness of this claim (does the 486 execute RISC integer instructions?), it was the thin edge of the wedge, and the beginning of a growing period of intellectual laziness within the computer trade press that has largely corrupted the terms RISC and CISC for most of the computer buying populace to this day.

The campaign to obfuscate the clear distinction between RISC and CISC moved into high gear with the advent of the modern x86 processor implementations employing fixed length control words to operate out-of-order execution data paths. These wide packets of control information would have been called microcode words a decade ago. However, x86 vendors have cleverly named them micro-ops (uops), RISC-ops (R-ops), or even RISC86 instructions in order to draw the inference that these are equivalent to the instructions of a RISC ISA. The popular technical press, like PC Magazine, latched onto this and routinely print side bars to CPU stories that explained how new processors like the Pentium II and the K7 are really just RISC processors with a bit of stuff in the first stage or two of the pipeline to handle that nasty old complex variable length x86 instruction set.

The primary fallacy of the “RISC and CISC have converged” school of thought is to ignore the distinction between an instruction set architecture (ISA) and the internal microarchitecture of an actual processor implementation. RISC and CISC refer to ISAs, which are abstract models of computer architectures as seen by the programmer. An ISA includes the programmer and compiler visible state of a computer, including all registers and flags, the encoding and semantics of all instructions, exception handling, and memory organization and semantics (little-endian vs big-endian, weakly-ordered vs strongly-ordered). An ISA does not tell computer engineers how an implementation must be realized.

Today’s modern x86 CISC microprocessor and high-end RISC microprocessor share a great deal of implementation details and are built using similar functional building blocks. The integer out-of-order execution back end of a Pentium II/III or K7 Athlon processor with its large group of renaming registers does closely resemble the integer data path of a RISC processor. This similarity is a major reason why x86 processors haven’t fallen hopelessly behind the performance of RISC microprocessors, but CISC processors still pay a large complexity tax. A modern x86 processor requires several extra pipe stages and about 40% larger instruction cache to analyze the variable length x86 instruction set and store pre-decode information. The x86 instruction decoders themselves consume one or two million transistors and are quite complex and prone to design errors that are only partially correctable using patchable microcode store. The modern x86 back-end execution engine (the so-called “RISC execution unit”) also has to devote extra resources to handle instruction dependencies related to condition codes and ensuring exceptions encountered, while processing micro-ops can be reported back as precise exceptions within the context of the originating x86 instruction.


Pages: « Prev   1 2 3 4 5 6   Next »

Be the first to discuss this article!