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

Rule of thumb: if a compiler or assembly programmer must know it to write a correct program, it is the ISA. If it only affects speed, hidden behind the same visible behaviour, it is microarchitecture.

1. ISA — the register names and count are part of the visible contract.
2. Microarchitecture — a predictor changes speed, not correctness; software never names it.
3. ISA — instruction length is how the decoder is defined to read the stream; software depends on it.
4. Microarchitecture — cache associativity is invisible to correctness; see Caches and Memory Hierarchy.
5. ISA — this is the subtle one. Architectural side effects like x86's status flags (carry, zero, sign, overflow) look like internal plumbing, but because a later instruction's behaviour depends on them, the compiler must reason about them to emit correct code. They sit in the visible contract, so they are ISA. Contrast this with how many pipeline stages compute the flag — that timing is microarchitecture. The test is always: "if this changed silently, could a correct program break?" For flags, yes → ISA.

The load/store rule: in RISC, arithmetic instructions touch registers only. Any arithmetic that reads or writes memory is CISC-only.

1. RISC-legal — all three operands are registers.
2. CISC-only — arithmetic reads two memory operands.
3. RISC-legal — a LW (load word) is allowed to touch memory; that is its whole job.
4. CISC-only — the multiply reads a memory operand [C] directly.

First convert the clock to a period. Why? The Iron Law needs $T_{cycle}$ (seconds per tick), not frequency (ticks per second). $T_{cycle}=\frac{1}{f}=\frac{1}{2\times 10^9\text{Hz}}=0.5\times 10^{-9}\text{s}=0.5\text{ns}$ Now plug in: $T=IC\times CPI\times T_{cycle}=10^9\times 2.5\times 0.5\times 10^{-9}\text{s}=1.25\text{s}$ What it means: a billion instructions, each averaging 2.5 slow-ish ticks, on a fairly fast clock, takes about 1.25 seconds.

RISC form (staging memory into registers, because arithmetic may not touch memory):

LW   r1, A       ; load A
LW   r2, B       ; load B
ADD  r1, r1, r2  ; register + register
SW   r1, A       ; store back to A

That is $IC=4$ instructions. $T=IC\times CPI\times T_{cycle}=4\times 1\times 0.4\text{ns}=1.6\text{ns}$

Forecast: RISC runs 2.5× the instructions, but each is far cheaper (CPI 1.1 vs 6) and the clock ticks faster (0.35 vs 0.5). Guess RISC. Verify — remember we are just plugging into the Iron Law $T=IC\times CPI\times T_{cycle}$ for each row: $T_{\text{CISC}}=6\times 6\times 0.5=18\text{ns}$ $T_{\text{RISC}}=15\times 1.1\times 0.35=5.775\text{ns}$ RISC wins ($5.775$ ns vs $18$ ns). Look at the figure: the tall orange CISC bar is dominated by its $CPI$ value; the short teal RISC bar shows a low $CPI$ and short $T_{cycle}$ crushing its larger $IC$ — exactly what the plum arrows label.

Again we simply re-evaluate the Iron Law $T=IC\times CPI\times T_{cycle}$ for the CISC row, changing only the middle factor: $T_{\text{CISC}}=6\times 2\times 0.5=6\text{ns}$ RISC is unchanged at $5.775$ ns. So $6>5.775$: RISC still wins, but only barely. The margin as a percentage of the CISC time is $\frac{T_{\text{CISC}}-T_{\text{RISC}}}{T_{\text{CISC}}}=\frac{6-5.775}{6}=\frac{0.225}{6}=0.0375=3.75\%$ This is the whole point: shrink CISC's $CPI$ enough and the low-$IC$ advantage nearly catches up. There is no law of nature declaring a winner — only a product of three factors.

1. 4 µops (load A, load B, add, store A) — exactly the RISC sequence from L2-b.
2. Effective cycles = decode + µops = $1+4=5$ cycles for one CISC instruction, so its effective $CPI=5/1=5$.
3. Pure RISC: $4$ instructions $\times 1$ cycle $=4$ cycles. Reading it: the "single fat instruction" costs 5 internal cycles vs the RISC 4 — the decode/crack overhead is the extra cycle. This is why modern x86-64 is "CISC outside, RISC inside": the fatness is convenience for the code stream, but the real work is still one small step at a time. See Microcode and Microarchitecture vs ISA.

• CISC size $=6$ bytes (one instruction).
• RISC size $=4\times 4=16$ bytes (four fixed 32-bit instructions).
• Ratio $=16/6\approx 2.67$. So the RISC version is about 2.67× larger in bytes for this snippet. What it means: CISC's original selling point (dense code when memory was scarce) is real and quantifiable here — even though RISC may run faster, it costs more instruction-memory footprint.

Real-world caveat (don't over-sell the 6 bytes): the "6 bytes" is the raw encoding, but real binaries rarely hit that on the page. CISC's variable-length instructions can force alignment padding so the next instruction or a branch target lands on a clean boundary, and both ISAs carry metadata overhead (relocation entries, symbol tables, ELF/PE headers). So the true on-disk density gap is usually smaller than the neat $2.67\times$ suggests — the ratio is an upper bound on CISC's advantage, not a guarantee. This is the tension Compilers and Code Generation must manage.

Decision: lean toward CISC-style dense encoding (or a compressed RISC variant). Justification via the numbers: L4-b showed RISC used $16$ bytes vs CISC's $6$ bytes — a $2.67\times$ footprint penalty. When speed is a non-goal but ROM bytes are the binding constraint, minimizing $IC$-encoding-size dominates the Iron Law's $T$. But apply the L4-b caveat honestly: that $2.67\times$ is a best case for CISC — alignment padding around variable-length instructions and fixed metadata overhead (headers, relocation tables) eat into the raw-byte win, so the real ROM saving is somewhat less. Even so, the direction still favours dense encoding. The classic RISC counter-move is compressed encodings (e.g. RISC-V "C" 16-bit instructions), which claw back density while keeping the simple pipeline — showing the dichotomy is a spectrum, not a wall.

Step 1 — convert clocks to periods first. $T_{cycle}=1/f$:

• A: $T_{cycle}=1/(3.0\times 10^9)=0.3333\text{ns}$.
• B: $T_{cycle}=1/(4.0\times 10^9)=0.25\text{ns}$.

Step 1 — times (plug each row into the Iron Law $T=IC\times CPI\times T_{cycle}$): $T_A=5\times 4.0\times 0.3333\text{ns}=6.667\text{ns}\left(=\frac{20}{3}\text{ns exactly}\right)$ $T_B=12\times 1.0\times 0.25\text{ns}=3.0\text{ns}$

Step 2 — winner and "how much faster." B is faster. Now be careful about what "X% faster" means — the convention must be stated, because dividing by the slow one and the fast one give different numbers:

• Convention we use (the standard one): "B is X% faster than A" ⇒ speed-up measured against the faster machine's time, i.e. divide the time saved by the faster time $T_B$. This answers "how much extra time does the slow machine burn, per unit of the fast machine's time?" $\text{percent faster}=\frac{T_A-T_B}{T_B}\times 100=\frac{\frac{20}{3}-3}{3}\times 100=\frac{\frac{11}{3}}{3}\times 100=\frac{11}{9}\times 100\approx 122.2\%$ So A takes about $122\%$ more time than B — equivalently B is "about 2.22× the speed."
• The other common phrasing — "A is Y% slower than B" ⇒ divide the time saved by the slower time $T_A$, which gives a different number: $\frac{T_A-T_B}{T_A}\times 100=\frac{\frac{20}{3}-3}{\frac{20}{3}}\times 100=\frac{11/3}{20/3}\times 100=\frac{11}{20}\times 100=55\%$ So B finishes in $T_B/T_A=3/(20/3)=9/20=0.45$, i.e. B runs in about $45\%$ of A's time ($55\%$ less time). Both statements describe the same pair of numbers — the only difference is the denominator, which is exactly why you must name it.

Step 3 — lever-by-lever why (read alongside the figure). All three levers of $T=IC\times CPI\times T_{cycle}$:

• $IC$ lever: A wins this one ($5<12$) — fewer, fatter instructions is the classic CISC advantage. This is B's only handicap.
• $CPI$ lever: B crushes it ($1.0$ vs $4.0$, a $4\times$ gap) — simple, regular instructions pipeline down to ~1 cycle each (Pipelining), whereas A's fat instructions are multi-cycle/microcoded.
• $T_{cycle}$ lever: B wins ($0.25$ ns vs $0.3333$ ns) — simpler decode lets the clock run faster ($4$ GHz vs $3$ GHz). Putting the three together: the product is $T_A/T_B=(\frac{5}{12})\times (\frac{4.0}{1.0})\times (\frac{0.3333}{0.25})=0.4167\times 4\times 1.333=2.22$. A's lone $IC$ win contributes the factor $0.4167$ (pulling toward A), but the $CPI$ factor of $4$ and the clock factor of $1.333$ multiply to $5.33$ against A — so their product $2.22$ still lands firmly in B's favour. Two strong levers beat one, and the Iron Law makes the margin exact rather than a hunch. This is the canonical RISC argument — and it depended entirely on the numbers, exactly as the Iron Law demands.