RISC vs. CISC (2000)
cs.stanford.edu
cs.stanford.edu
Other similarly styled informational sites created by students in this course over the years can be found here: http://cs.stanford.edu/people/eroberts/courses/soco/
RISC didn't die and CISC didn't die... "RISC vs. CISC" died instead.
...aside from being orders of magnitude more of an ass-pain if you ever have to write software that actually deals with machine code (at least on x86; perhaps other CISCs aren't as bad).
Simple example: given an instruction boundary, find the preceding instruction boundary. On most any RISC it's trivial (subtract 4, or perhaps 2 in some cases). On x86...I'm not an expert, but I'm about 80% confident it's basically impossible to do in the general case.
1. I was talking about external as in the memory hierarchy not development effort.
>(at least on x86; perhaps other CISCs aren't as bad).
This, the PDP-11 machines have a lovely instruction set for example.
I, for one, am slightly puzzled why genetic algos never became mainstream in any computational field.
Genetic programming is also a machine learning technique where you generate random answers then mix them together until it increases the fitness function. Since it knows nothing about the actual problem space, it runs very slowly yet doesn't work better than something more sensible like simulated annealing.
But another way you can get an advantage in clock speed, die size, and power is to go to a smaller fab process.
And given Moore's law, die shrinks marched ever on, and the next shrink was never that far away. And Intel had a boatload of money to push their fabs ahead of most everyone else.
(Yes, this is pretty hand-wavy, and you can pick a lot of nits, but I think there's a lot of truth to it.)
RISC won and all CPUs are now RISC CPUs. Even the x86 CPUs with CISC instruction sets are now RISC CPUs.
This is done by using a thin instruction "cracking" layer that turns CISC instructions into a series of "micro-ops" (equivalent to simple RISC operations). Additionally, most RISC CPUs still need to break some of their instructions down into micro-ops.
It just didn't require the death of the x86 instruction set.
Old CISC: Microcoded interpreters interpreting higher level ISAs.
"New" CISC: JITs transpiling higher level ISAs into microcode.
Old RISC: Let's skip the middle man and deal with 80s CISC microcode directly, so as to simplify instruction decoding and pipelining.
Somewhat new RISC: Oh wait, instruction decoding is trivial, at high frequencies we can't ignore the fact that i.e. multiplies inherently take longer to compute than adds, and icache density really matters in an age when DRAM is orders of magnitude slower than the SRAM it feeds. I guess we'd better start reading those Ars Technica articles on the design of the Pentium from the late 90s.
Is "new" CISC wearing old RISC's clothing, or is new RISC just finally catching up to 90s "new" CISC?
Oh about the RISC vs CISC silly debate: IS is Instruction Set, which one? The one visible by the compiler/user, so saying that x86 are RISCs because their implementation use a RISC internally is st... ahem incorrect.
1: but not a classical one.
Memory is considerably slower than CPU. CISC can be thought of as a kind of data compression for code. The article does mention this, but kind of glosses over its importance. In many cases a load from RAM can take hundreds of clock cycles, so minimizing that is a huge win. It also makes programs load faster since smaller code footprints require less disk or network access.
1) Cisc code isn't really any better in some languages, e.g. C++, which uses heavy code duplication. 2) The instruction cache these days is pretty fucking huge. Any tight loop will fit in it just fine, and it's hardly like you're thrashing the cache often at all (except, again in cases where you would already be thrashing the cache on CISC). It's very difficult to find a scenario where RISC is held back by the instruction cache where CISC would not be. Obviously, if you shrink the cache and use -Os and try not to duplicate code, you could probably run into this scenario more often, but it's just not a very relevant argument. See: why people don't bother to use thumb instructions on ARM. It's very rarely the bottleneck for a chunk of code. In fact, the only place I'd expect to see it make a difference is either a) with dynamic translation, ala Qemu, where you might rapidly thrash a lot of code pages, and b) on application load on heavily duplicated code (again, think C++).
In fact, I'd argue that the RISC vs CISC argument is less relevant than ever these days:
+ Compilers hide more assembly than ever, removing the need for human readability of underlying instructions.
+ Memory bandwidth and branch prediction are both larger issue on both architectures than decoding of instructions.
+ Intel has shown low-power CISC processors are in fact viable (atom and celeron are both respectable), although it looks difficult to get a risc-like performance/watt out of them.
+ Most modern cisc code translates VERY CLEANLY to a risc-like microcode. Assuming the translation cache is hot, translation really shouldn't add much overhead.
No, I think the major downsides of CISC are maintainability (both in terms of ISA and actually laying down logic) and in the difficulty of correct implementation semantics across diverse implementations, something I'm frankly amazed at Intel's ability to reliably pull off.
In my opinion, we'll have following things to come:
- Simple in-order execution CPUs with tons of ALUs, as the generalization of current GPUs (a la Larrabee or AMD/nVidia/ARM VLIW). This would be used for graphics and signal processing.
- Complex OoOE CPUs with expressive ISA for complex r-r/r-m/m-m operations, transactional operations, runtime-defined opcodes, focused to maximize sequential execution. With operating system support, it could allow to re-optimize code, defining opcodes for groups of operations, so code could get faster/smaller (code self-compression de facto).
No mention of ARM (which is a RISC architecture)? No mention of power usage advantage? You're not just removing those code translation transistors to simplify your chip, you're also removing them to reduce power usage!
# uname -a
Linux beaglebone 3.8.13-bone47 #1 SMP armv7l GNU/Linux
# ./misc
Little Endian
The only BIG endian systems I have left are Sparc64 OpenBSD boxes (Sun Netra T1s).
# uname -a
OpenBSD netra.w8rbt.org 5.6 GENERIC#187 sparc64
# ./misc
Big Endian
For a time. And then Intel just marched on and everyone else collapsed under rising R&D costs and shrinking market share.
Remember how IBM couldn't raise the clock speed on their PowerPC (RISC!) chips, so Apple switched to the more powerful Intel architecture?