Visual walkthrough — CISC vs RISC philosophies

We are chasing one number: how many seconds does a program take? Call that number $T$ (for Time). By the end you will see exactly which knobs move $T$ up or down.

Step 1 — What a program actually is (counting the work)

WHAT. A program, when it finally runs, is just a long list of tiny commands the CPU obeys one after another. Each command is an instruction. Let $N$ = the total count of instructions the CPU actually executes.

WHY $N$? Before we can time anything, we must count the work. You cannot say "this trip took a while" without first knowing how many steps you took. $N$ is our step count.

PICTURE. Below, the same job A = A + B is written two ways. CISC uses a short stack of instructions (small $N$); RISC uses a taller stack (large $N$). Same job, different height of the tower.

Step 2 — Instructions don't finish instantly: the cycle

WHAT. A CPU has a heartbeat — a clock that ticks. One tick is one clock cycle. No instruction finishes in "zero time"; each one eats some whole number of ticks.

WHY a cycle? We need a unit of effort smaller than a whole instruction, because some instructions are lazy (1 tick) and some are heavy (many ticks). The cycle is the ruler we measure instruction-effort with.

PICTURE. A row of clock ticks. A simple RISC ADD fits in 1 tick. A rich CISC ADD [A],[B] (which secretly loads, adds, and stores) sprawls across several ticks.

Step 3 — A tick is not free: it costs seconds

WHAT. Each tick of the clock lasts a fixed amount of real time. Call it $T_c$ — the cycle time, measured in seconds. A 2 GHz clock ticks 2 billion times a second, so each tick is $T_c=1/(2\times 10^9)=0.5$ nanoseconds.

WHY $T_c$? CPI told us how many ticks. But ticks aren't seconds until we know how long one tick lasts. $T_c$ is the exchange rate: ticks → seconds.

PICTURE. A single tick stretched out to show its width in nanoseconds. Simple hardwired RISC control lets the tick be narrow (short $T_c$); complex CISC control forces a wider tick (long $T_c$), because more logic must settle before the next tick.

Step 4 — Multiply the three knobs into total time

WHAT. Now chain the units together. We have:

$T=\underset{\text{instructions}}{\underbrace{N}}\times \underset{\frac{\text{cycles}}{\text{instruction}}}{\underbrace{\text{CPI}}}\times \underset{\frac{\text{seconds}}{\text{cycle}}}{\underbrace{T_c}}$

WHY multiply, and why these three? Watch the units cancel like a chain — this is the whole reason the formula is a product and not a sum:

$\cancel{\text{instr}}\times \frac{\text{cycles}}{\cancel{\text{instr}}}\times \frac{\text{seconds}}{\cancel{\text{cycles}}}=\text{seconds}$

Each factor is a conversion: instructions → cycles → seconds. Multiplication (not addition) is forced because each stage scales the previous one — double the instructions and double the cycles-each and you quadruple time.

PICTURE. Three sliders labelled $N$, CPI, $T_c$ feeding into one box that outputs $T$. Turning any slider up stretches the output bar.

Step 5 — CISC's move: shrink $N$, pay for it elsewhere

WHAT. CISC attacks the first knob. One rich instruction like ADD [A],[B] does the work of four RISC instructions, so $N$ drops.

WHY it can backfire. That single instruction still has to load, add, and store inside — so its CPI is high (many ticks). And the extra decoding logic widens the tick, so $T_c$ grows too. CISC pushed one slider down and accidentally shoved two others up.

PICTURE. The three-slider box again, in CISC colours: the $N$ slider drops, but the CPI and $T_c$ sliders rise — the output bar $T$ barely shrinks (or grows).

Step 6 — RISC's move: let $N$ grow, crush CPI and $T_c$

WHAT. RISC accepts the taller tower — more instructions, bigger $N$. In exchange, every instruction is simple and uniform, so:

• CPI is driven toward $1$ (each instruction ≈ one tick, thanks to Pipelining),
• $T_c$ shrinks (simple hardwired control, no microcode to slow the tick).

WHY it can win. RISC pushed one slider up ($N$) but hauled two sliders down (CPI, $T_c$). If the downward pulls are strong enough, the product $T$ still comes out smaller.

PICTURE. The slider box in RISC colours: $N$ rises, but CPI and $T_c$ collapse, and the output bar $T$ ends up shorter than CISC's.

Step 7 — Put real numbers on the bet

WHAT. Take the parent note's numbers and turn them into bars we can compare directly.

WHY this is the whole argument. RISC used 50% more instructions ($1.5$M vs $1.0$M) yet finished in 1.65 vs 5.0 — about $3\times$ faster. The bigger $N$ was worth it because CPI fell $4.0\to 1.1$ and $T_c$ fell $1.25\to 1.0$.

PICTURE. Two stacked-factor bars. CISC's bar is short on $N$ but tall overall; RISC's bar is taller on $N$ but far shorter overall.

Step 8 — The degenerate cases (when the bet is a bad bet)

WHAT. No formula wins always. Let's push the knobs to extremes.

Case A — CPI can't reach 1. If a workload is full of dependencies and cache misses, pipelining stalls and RISC's CPI creeps up. Then RISC's larger $N$ hurts with no CPI reward.

Case B — $T_c$ already floored. If both designs hit the same transistor limits, $T_c$ equalises. The battle collapses to just $N\times \text{CPI}$, and a CISC with clever microcode can compete.

Case C — memory is the bottleneck, not the CPU. If the program spends its life waiting on RAM, neither $N$, CPI, nor $T_c$ matters much — the whole equation is dwarfed by memory latency. This is why modern chips (x86 vs ARM) converged: silicon internals matter less than caches and decoders.

PICTURE. The RISC vs CISC bars redrawn under each stressed case — the gap shrinks, vanishes, or even flips.

The one-picture summary

The whole walkthrough on one canvas: three knobs ($N$, CPI, $T_c$) feed one product $T$; CISC drops $N$ but inflates the other two; RISC inflates $N$ but crushes the other two; the winner is whoever's product bar is shorter — and the break-even condition tells you exactly when.

Flashcards