The current technological context
Let's now briefly consider the current state of the three parameters that defined the technological matrix from which RISC arose, in light of the preceding discussion of post-RISC advances.
Storage and Memory
Today's memory is fast and cheap; anyone who's installed a Microsoft program in recent times knows that many companies no longer consider code bloat an issue.* Thus the concerns over code size that gave rise to CISC's large instruction sets have passed.* Indeed, post-RISC CPUs have ever-growing instruction sets of unprecedented size and diversity, and no one thinks twice about the effect of this on memory usage.* Memory usage has all but ceased to be a major issue in the designing of an ISA, and instead memory is taken for granted.
Compilers
Compiler research has come a long way in the past few years.* In fact, it has come so far that next-generation architectures like Intel's IA-64 (which I talk about here) depend wholly on the compiler to order instructions for maximum throughput; dynamic, OOO execution is absent from the Itanium. The next generation of architectures (IA-64, Transmeta, Sun's MAJC) will borrow a lot from VLIW designs.* VLIW got a bad wrap when it first came out, because compilers weren't up to the task of ferreting out dependencies and ordering instructions in packets for maximum ILP.* Now however, it has become feasible, so it's time for a fresh dose of the same medicine that RISC dished out almost 20 years ago: move complexity from hardware to software.*
VLSI
Transistor counts are extremely high, and they're getting even higher.* The problem now is not how do we fit needed functionality on one piece of silicon, but what do we do with all these transistors.* Stripping architectures down and throwing rarely-used functionality overboard is not a modern design strategy.* In fact, designers are actively looking for things to integrate onto the die to make use of the wealth of transistor resources.* They're asking not what they can throw out, but what they can include.* Most of the post-RISC features are a direct result of the increase in transistor counts and the "throw it in if it increases performance" approach to design.**
The guilty parties
For most of the aforementioned post-RISC transgressions, the guilty parties include such "RISC" stalwarts as the MIPS, PPC, and UltraSPARC architectures.* Just as importantly, the list also includes so-called "CISC" chips like AMD's Athlon and Intel's P6.* To really illustrate the point, it would be necessary to take two example architectures and compare them to see just how similar they are.* A comparison of the G4 and the Athlon would be most appropriate here, because both chips contain many of the same post-RISC features.* The P6 and the Athlon are particularly interesting post-RISC processors, and they deserve to be treated in more detail.* (This, however, is not the place to take an in-depth look at a modern CPU.* I've written a technical article on the Athlon that should serve to illustrate many of the points I've made here.* I hope to start work soon on an in-depth look at the G4, comparing it throughout to the Athlon and P6.)* Both the Athlon and the P6 run the CISC x86 ISA in what amounts to hardware emulation, but they translate the x86 instructions into smaller, RISC-like operations that fed into a fully post-RISC core.* Their cores have a number of RISC features (LOAD/STORE memory access, pipelined execution, reduced instructions, expanded register count via register renaming), to which are added all of the post-RISC features we've discussed.* The Athlon muddies the waters even further in that it uses both direct execution and a microcode engine for instruction decoding.* A crucial difference between the Athlon (and P6) and the G4 is that, as already noted, the Athlon must translate x86 instructions into smaller RISC ops.**
In the end,* I'm not calling the Athlon or P6 "RISC," but I'm also not calling them "CISC" either.* The same goes for the G3 and G4, in reverse.* Indeed, in light of what we now know about the the historical development of RISC and CISC, and the problems that each approach tried to solve, it should now be apparent that both terms are equally nonsensical when applied to the G3, G4, MIPS, P6, or K7.* In today's technological climate, the problems are different, so the solutions are different.* Current architectures are a hodge-podge of features that embody a variety of trends and design approaches, some RISC, some CISC, and some neither.* In the post-RISC era, it no longer makes sense to divide the world into RISC and CISC camps.* Whatever "RISC vs. CISC" debate that once went on has long been over, and what must now follow is a more nuanced and far more interesting discussion that takes each platform--hardware and software, ISA and implementation--on its own merits.
