RISC vs CISC

For twenty years this was the fiercest argument in computer architecture, fought in conference papers, product launches and religious-grade internet flame wars. On one side, CISC — the Complex Instruction Set Computer, whose champion is \text{x86}. On the other, RISC — the Reduced Instruction Set Computer, whose descendants are ARM and RISC-V. The debate was never really about the number of instructions. It was about a philosophy: should the hardware be clever, or should the hardware be simple and let the compiler be clever?

The delicious twist — which we build up to — is that both sides eventually won, because the modern \text{x86} chip in a laptop is secretly a RISC machine wearing a CISC mask.

CISC: a rich, dense instruction set

CISC was born when memory was tiny and precious and compilers were primitive. The guiding idea: make each instruction do a lot, so a program needs fewer of them and takes less space, and so a human writing assembly has powerful building blocks. The \text{x86} family (1978 onward) is the archetype:

Variable-length encoding — an instruction is anywhere from 1 to 15 bytes. Common ops are short; rare ones are long.
Memory operands in arithmetic — add [eax], ebx reads memory, adds, and writes it back, all in one instruction (a register–memory model).
Rich addressing modes — a single operand can be [base + index*scale + disp].
Microcode — a complex instruction like rep movsb (copy a whole string) is implemented by a tiny internal program burned into the chip.

The dream was that one dense instruction would be faster than several simple ones. The reality, by the 1980s, was that decoding all that variety was a nightmare, and studies showed compilers barely used the fancy instructions.

RISC: few instructions, all simple and regular

In the early 1980s, Berkeley (Patterson) and Stanford (Hennessy) asked a heretical question: what if we removed the complexity? Measurements showed real programs spent almost all their time in a handful of simple instructions. So RISC keeps only those, and makes them uniform:

Fixed 32-bit encoding — every instruction is exactly one word, so decoding is trivial and the next instruction's address is always "PC + 4".
Load–store — only load/store touch memory; arithmetic is register-to-register (see the ISA as a contract).
Lots of registers — 32 of them, so the compiler rarely has to spill to memory.
Hardwired control, no microcode — each instruction is simple enough to execute directly, which makes deep pipelining natural.

RISC bets that a stream of simple, identical-shaped instructions can be pipelined so smoothly that it beats a stream of complex ones — even though there are more of them.

Head to head

Property	CISC (x86)	RISC (ARM, RISC-V, MIPS)
Instruction length	variable (1–15 bytes)	fixed (usually 32 bits)
Memory operands in ALU ops	yes (register–memory)	no (load–store only)
Addressing modes	many, complex	few, simple
Control implementation	microcoded	hardwired
Registers	few (8 legacy, 16 in x86-64)	many (32)
Instructions per program (IC)	lower	higher
Cycles per instruction (CPI)	higher, less predictable	lower, pipelines cleanly
Decode difficulty	hard	easy
Design philosophy	clever hardware	clever compiler

The iron law is the referee

The whole debate is really a fight over two factors of the iron law, \text{CPU time} = \text{IC} \times \text{CPI} \times T_{\text{cycle}}:

\underbrace{\text{CISC}}_{\text{low IC, high CPI}} \qquad\text{vs}\qquad \underbrace{\text{RISC}}_{\text{high IC, low CPI}}.

CISC pushes IC down (one big instruction replaces several) but CPI up (that instruction is slow and messy to execute). RISC does the opposite: IC up (more, smaller instructions) but CPI down (each pipelines beautifully, often near CPI = 1). Since it's the product that determines speed, the winner is whoever gets a better combined result — and the clock term T_{\text{cycle}} also favours RISC, because simple hardware clocks faster. Let's put concrete numbers on it.

// The RISC vs CISC trade, framed by the iron law: time = IC x CPI x cycle_time. // Same program; CISC needs fewer instructions but each costs more cycles. function cpuTime(ic: number, cpi: number, ghz: number): number { return (ic * cpi) / (ghz * 1e9); // seconds } // CISC: 1.0 billion instructions, CPI 3.5, but a simpler-to-clock RISC hits 3.5 GHz vs 3.0. const cisc = cpuTime(1.00e9, 3.5, 3.0); // RISC: ~30% more instructions (1.3B) but CPI 1.2 and a faster clock. const risc = cpuTime(1.30e9, 1.2, 3.5); console.log(`CISC: IC=1.00e9 CPI=3.5 @3.0GHz -> ${(cisc * 1e3).toFixed(2)} ms`); console.log(`RISC: IC=1.30e9 CPI=1.2 @3.5GHz -> ${(risc * 1e3).toFixed(2)} ms`); console.log(`RISC is ${(cisc / risc).toFixed(2)}x faster despite running MORE instructions`);

The plot twist: the debate ended in a truce

Here is how the argument actually resolved. Starting with the Pentium Pro (1995), Intel and AMD kept the \text{x86} contract on the outside — for backward compatibility with the mountain of existing software — but built a RISC engine on the inside. A hardware decoder at the front of the pipeline chops each complex, variable-length \text{x86} instruction into one or more simple, fixed-shape micro-operations (µops). The rest of the chip — the out-of-order core that does the real work — only ever sees these clean, RISC-like µops.

So a modern \text{x86} processor is, quite literally, a RISC microarchitecture behind a CISC instruction-set façade. RISC won the engineering argument (everyone builds RISC-like cores); CISC won the compatibility argument (\text{x86}'s vast software base kept it alive). The category labels stopped being a useful way to compare real chips somewhere around the late 1990s.

Because the CISC façade is not free. Decoding variable-length \text{x86} instructions into µops takes power and silicon, and — crucially — it's hard to decode many instructions per cycle because you can't tell where each one starts until you've decoded the previous one. A fixed-length ISA like ARM lets you decode 8 instructions in parallel trivially, which helps a wide out-of-order core stay fed. Apple's M-series chips (2020) exploited exactly this: a very wide decoder that \text{x86}'s variable length makes awkward. So even though both cores are RISC-like inside, the front end the ISA forces on you still matters for power efficiency — which is why the argument's ghost lives on in your phone and your laptop's battery life.

The R in RISC is the most misread letter in computing. People assume it means a RISC chip has a small number of instructions. It doesn't — RISC-V with all its extensions has hundreds of instructions, more than some old CISC machines. "Reduced" refers to the complexity of each instruction: each does one simple thing in a predictable time. The real distinction is regularity — fixed length, load–store, hardwired control — not a small opcode count. Judge an ISA by how uniform its instructions are, not by how many it has.

What to take away

RISC vs CISC is best remembered not as "who won" but as a case study in the iron law: two designs balancing IC against CPI, with the clock quietly favouring simplicity. The modern answer — decode a compatible CISC contract into RISC micro-ops — is a beautiful example of the architecture seam at work: the outside contract and the inside implementation are decoupled, and each optimises for a different thing. From here we stop comparing and start building: the next lesson opens up RISC-V's actual registers and 32-bit encoding.