ISA (Instruction Set Architecture) — RISC vs CISC: Visual walkthrough

Step 1 — What are we even trying to measure?

WHAT. We want a single number that says "this program was fast" or "this program was slow." The honest number is: how many seconds did the CPU spend actually running this program?

WHY. People argue about clock speed, instruction counts, cache size — but none of those is speed. What we can cleanly reason about with the formula below is the time the processor is busy executing our program. Call it $T$ .

$T = \frac{seconds}{program}$

$T$ — the CPU time for the program, measured in seconds.
" $per program$ " — we are timing one whole run, not one instruction.

PICTURE. A stopwatch that runs only while the CPU is busy on our program (it pauses during I/O waits). That busy gap — nothing else — is $T$ .

Figure — ISA (Instruction Set Architecture) — RISC vs CISC

Everything below is a way to break $T$ into pieces we can control.

Step 2 — A program is made of instructions

WHAT. A program isn't one blob — it's a list of tiny commands the CPU executes one after another. Each command is an instruction (an ADD, a LOAD, a JUMP). We count how many the CPU runs in total and call that number $I C$ — the instruction count.

WHY. Because this is the first place the ISA choice shows up. A CISC program does the same task in fewer, fatter instructions; a RISC program uses more, leaner ones. If we want the formula to "see" that difference, $I C$ must be a factor.

$I C = \frac{instructions}{program}$

$I C$ — how many instructions the CPU actually executes for this program.
Note: this is dynamic count (instructions actually run), not the size of the source file.

PICTURE. A stack of instruction cards, one per command. RISC's stack is taller (more cards); CISC's is shorter (fewer, heavier cards).

Step 3 — Each instruction costs some clock cycles

WHAT. A CPU is driven by a clock: a signal that ticks at a fixed rate, like a metronome. Each tick is one cycle. An instruction isn't instant — it takes some whole number of cycles to finish. Averaged over the whole program, we call this the cycles per instruction, written $C P I$ .

WHY. This is the second place the ISA choice shows up. A CISC ADD [mem],[mem] might chew through 5 cycles (load, load, add, store...). A RISC ADD r1,r1,r2 finishes in about 1 cycle. So $C P I$ is exactly where "simple vs complex instruction" becomes a number.

$C P I = \frac{cycles}{instruction}$

$C P I$ — average number of clock ticks each instruction consumes.
Low $C P I$ = each instruction is cheap in time (the RISC dream, $\approx 1$ ).
High $C P I$ = each instruction is expensive (typical of fat CISC instructions).

PICTURE. A metronome ticking. One RISC instruction fits in one tick; one CISC instruction spans several ticks — the red bracket spans 5 ticks.

Step 4 — Each cycle lasts some number of seconds

WHAT. How long is one tick? That depends on the clock frequency $f$ — how many ticks per second (measured in hertz, Hz). The duration of one tick is just its reciprocal, the cycle time $T_{cy c l e}$ .

WHY. We used the word "cycle" in Step 3, but a cycle is not a unit of time by itself — it's a count. To turn cycles into seconds (our goal from Step 1) we must know how many seconds each tick lasts. That bridge is $T_{cy c l e}$ .

Why the reciprocal, and not something else? Frequency answers "how many ticks per second?" We want the inverse question — "how many seconds per tick?" Flipping a rate $\frac{ticks}{s}$ gives $\frac{s}{tick}$ . That's exactly the unit we need.

$T_{cy c l e} = \frac{seconds}{cycle} = \frac{1}{f}$

$f$ — clock frequency, ticks per second (e.g. $2 GHz = 2 \times 1 0^{9}$ ticks/s).
$T_{cy c l e}$ — seconds per tick (e.g. $1/ (2 \times 1 0^{9}) s = 0.5 ns$ , since $1 ns = 1 0^{- 9} s$ ).
This is the third place the ISA choice shows up: simple RISC decode lets the clock tick faster (smaller $T_{cy c l e}$ ); complex CISC decode can force a slower clock.

PICTURE. A single tick zoomed in, with its width labelled in seconds. Faster clock ⇒ narrower tick.

Step 5 — Chain the three pieces together (the multiply-and-cancel trick)

WHAT. We now have three fractions. We multiply them. The magic is that the shared units cancel like fractions in arithmetic, leaving exactly the thing we wanted in Step 1: seconds per program.

WHY. This is the whole derivation. We never assumed the formula — we built $\frac{s}{prog}$ by laying down bridges: program → instructions → cycles → seconds. Each factor is one bridge, and where two bridges meet, the shared unit cancels.

T = I C \frac{instructions}{program} \times C P I \frac{cycles}{instruction} \times T_{cy c l e} \frac{seconds}{cycle}

Watch the units cancel (this is why it's legal, not a coincidence). To keep it readable we abbreviate the unit words as $instr$ = instructions, $cyc$ = cycles, $prog$ = program, $s$ = seconds — the three grouped factors are still exactly $I C$ , $C P I$ , $T_{cy c l e}$ from above:

I C \frac{instr}{prog} \cdot C P I \frac{cyc}{instr} \cdot T_{cy c l e} \frac{s}{cyc} = \frac{s}{prog} = T ✓

Naming the factors gives the boxed result:

$T = I C \times C P I \times T_{cy c l e}$

$I C$ — instructions per program (Step 2).
$C P I$ — cycles per instruction (Step 3).
$T_{cy c l e}$ — seconds per cycle (Step 4).
$T$ — seconds per program (Step 1). Goal reached.

PICTURE. Three fraction-tiles laid end to end; the touching edges (instruction↔instruction, cycle↔cycle) glow and cancel, leaving one arrow from "program" to "seconds."

Step 6 — RISC and CISC play the same law, different levers

WHAT. Same formula, same three knobs. RISC and CISC just turn them in opposite directions.

WHY. This is the payoff of the whole page: the RISC-vs-CISC argument is not three separate stories. It is one equation pulled two ways.

Knob	CISC turns it…	RISC turns it…	Why (the ISA cause)
$I C$	down ↓	up ↑	CISC's fat instructions do more per instruction; RISC needs more small ones (load/store rule — see Registers and the Register File)
$C P I$	up ↑	down ↓	Fat CISC instructions take many cycles; lean RISC instructions pipeline to ~1 (see Pipelining)
$T_{cy c l e}$	up ↑	down ↓	Complex/microcoded decode is slow (see Microcode); simple hardwired decode ticks fast

The key insight: because the three knobs multiply, making one small while another grows can leave the product either way. There is no universal winner — it depends on the workload.

PICTURE. Two bar-triples for the same task. CISC: short $I C$ bar, tall $C P I$ and $T_{cy c l e}$ bars. RISC: tall $I C$ bar, short $C P I$ and $T_{cy c l e}$ bars. The red total-time bar underneath shows RISC's product is smaller for this workload.

Worked example Plug in real numbers (Forecast → Verify)

Design	$I C$	$C P I$	$T_{cy c l e}$
CISC	$8$	$5$	$0.5 ns$
RISC	$16$	$1.2$	$0.4 ns$

Forecast: RISC doubles $I C$ but slashes $C P I$ ~4× and speeds the clock — guess RISC wins. $T_{CISC} = 8 \times 5 \times 0.5 = 20 ns$ $T_{RISC} = 16 \times 1.2 \times 0.4 = 7.68 ns$ RISC wins here. Steel-man: if $C P I$ were equal, CISC's lower $I C$ would win — the law is neutral. ✔

Step 7 — The degenerate & edge cases (never let a knob vanish silently)

WHAT. A formula you trust is one you've pushed to its extremes. Let's set each knob to a limit and see it stay sane.

WHY. The contract: the reader must never hit a scenario we didn't show.

$C P I \to 1$ (the pipelining ideal). Best case for RISC: one instruction finishes every cycle. Then $T = I C \times T_{cy c l e}$ . You cannot go below $C P I = 1$ on a simple single-issue pipeline — one instruction can't take less than one cycle to retire. (Superscalar CPUs break this by finishing several per cycle, i.e. $C P I < 1$ — a topic for Microarchitecture vs ISA.)
$I C \to 1$ (the CISC dream). Imagine one god-instruction doing the whole program. Then $T = C P I \times T_{cy c l e}$ , but that single instruction's $C P I$ would be enormous — the work didn't vanish, it moved into $C P I$ . Nothing is free.
$T_{cy c l e} \to 0$ (infinitely fast clock). Then $T \to 0$ ? Physically no: past a limit, faster clocks need more voltage → heat → the chip melts. The formula permits it; physics doesn't. This is the power wall.
Any knob $= 0$ . $T = 0$ only if $I C = 0$ (an empty program — no work). $C P I$ and $T_{cy c l e}$ can never truly be $0$ : an instruction that took zero cycles, or a cycle that took zero seconds, isn't a real event.

PICTURE. A "conservation of work" seesaw: pushing $I C$ down forces $C P I$ up so the total-work area stays roughly fixed. The red area (total time) is what we actually fight to shrink.

The one-picture summary

Everything on one canvas: the unit-cancellation chain across the top (program → instructions → cycles → seconds), the boxed Iron Law in the middle, and the two-lever RISC/CISC comparison below — with the red total-time bars showing who wins for the example workload.

Recall Feynman retelling — say it in plain words

I wanted to know how fast a program is, so I timed the whole thing — but carefully: only the seconds the CPU was actually busy on my program (CPU time), not the extra waiting for disk or for other programs. That busy time is $T$ , in seconds per program. But seconds is too big a lump, so I chopped it up. A program is a pile of instructions — that's knob one, how many instructions ( $I C$ ). Each instruction takes some ticks of the CPU's clock — knob two, cycles per instruction ( $C P I$ ). And each tick lasts some seconds — knob three, seconds per cycle ( $T_{cy c l e}$ ). I multiplied all three, the middle units cancelled like ordinary fractions, and out popped seconds per program again — the Iron Law: $T = I C \times C P I \times T_{cy c l e}$ . Then I noticed RISC and CISC aren't two different stories: they're the same three knobs turned opposite ways. CISC makes fewer, fatter instructions (small $I C$ , big $C P I$ and $T_{cy c l e}$ ); RISC makes many lean ones (big $I C$ , tiny $C P I$ and $T_{cy c l e}$ ). Because the knobs multiply, neither always wins — it depends on the job. And when I pushed each knob to its extreme, the work never disappeared, it just slid into another knob. That's the whole idea.

Recall Quick self-test

The three factors of the Iron Law ::: $I C$ (instructions/program), $C P I$ (cycles/instruction), $T_{cy c l e}$ (seconds/cycle) Does the Iron Law govern CPU time or wall-clock time? ::: CPU time (busy time); wall-clock also includes I/O waits and context switches Which knob does CISC make smaller, and which knob pays for it? ::: $I C$ smaller; $C P I$ (and often $T_{cy c l e}$ ) grow to pay Why can't a simple single-issue pipeline have $C P I < 1$ ? ::: One instruction can't retire in less than one cycle Why is $T_{cy c l e} \to 0$ physically impossible? ::: Faster clocks need more voltage → heat → the power/thermal wall In the worked example, why does RISC win despite $2 \times$ the instruction count? ::: Its $C P I$ drop (~4×) and faster clock more than cancel the higher $I C$

Connections: 4.1.03 ISA (Instruction Set Architecture) — RISC vs CISC (Hinglish) · CPI and the Iron Law of Performance · Pipelining · Microcode · Microarchitecture vs ISA · Registers and the Register File · Compilers and Code Generation