Visual walkthrough — Load - store architecture model

Parent: Load/store architecture model (5.1.9) This page rebuilds the parent's central result — that a load/store machine, despite issuing more instructions, can finish a job in the same or less time — as a picture-by-picture derivation. We assume you know nothing. Every symbol is earned before it appears.

---

Step 0 — The one word we cannot skip: register

Before any formula, we need one object. A register is a tiny storage box inside the CPU that holds one number. It is not memory — it is closer, faster, and there are only a handful of them.

Look at the picture. The CPU is a small room. The registers are the few boxes on the desk. Memory is the giant wall of shelves across the street. The only doors between them are labelled LOAD (fetch a box from the shelves onto the desk) and STORE (carry a box back). The rule of a load/store architecture is drawn in red: the arithmetic unit's hands never reach across the street. It touches only desk boxes.

---

Step 1 — What a job is: counting operations

WHAT. We describe a computation by how many real arithmetic/logic steps it needs. Call that number:

$N_{\text{ops}}$

• $N_{\text{ops}}$ — how many add / multiply / compare actions the algorithm truly requires. It is a property of the problem, not the machine.

WHY. Both machine styles must do the same math, so $N_{\text{ops}}$ is the fair common ground. What differs is the extra instructions each style needs to move data around.

PICTURE.

Our running example is $c=a+b$ where $a$, $b$ live in memory and $c$ goes back to memory. The math itself is one add, so $N_{\text{ops}}=1$. Everything else on this page is bookkeeping about the doors.

---

Step 2 — Counting instructions for each style

WHAT. Two machine philosophies (see RISC vs CISC philosophy):

• Register-memory (x86-like): an arithmetic instruction is allowed to reach into memory. So one instruction can load-add-store.
• Load/store (RISC-like): arithmetic sees only registers, so every memory value needs its own door instruction.

WHY this formula and not something fancier. We are only counting boxes moved through doors. For $c=a+b$: $N_{\text{ops}}=1$, $N_{\text{loads}}=2$ (fetch $a$, fetch $b$), $N_{\text{stores}}=1$ (write $c$). So:

$I_{\text{rm}}=1,I_{\text{ls}}=1+2+1=4$

PICTURE.

The load/store column is taller — 4 bricks against 1. If instruction count were the whole story, we'd stop here and declare register-memory the winner. It is not the whole story, and the next steps show why.

---

Step 3 — The hidden variable: time per instruction

WHAT. Instructions are not equal in cost. We measure cost in clock cycles. A clock cycle is one tick of the CPU's internal metronome. Define:

$\text{CPI}=\text{Cycles Per Instruction (average)}$

• $\text{CPI}$ — on average, how many metronome ticks each instruction consumes. Small is good.

WHY we introduce this now. Step 2 counted instructions but pretended each takes the same time. That is the mistake the parent note warns about. A register-memory ADD [addr], EAX secretly does read-modify-write; if memory is slow, that one instruction sits and waits for many ticks.

PICTURE.

Two instructions, same brick-count "1", but wildly different widths in time. The red bar is a memory-touching instruction dragging on a cache miss (a "miss" = the value wasn't in the fast nearby cache, so we wait for the far shelves — see Memory hierarchy). Width, not count, is what a clock measures.

---

Step 4 — Overlap: why the tall column shrinks

WHAT. A pipeline splits each instruction into stages (fetch, decode, execute, memory, write-back) and works on several instructions at once, like an assembly line — see Instruction pipelining. So while a slow LOAD waits on memory, an independent ADD can be marching through another stage.

WHY this matters here. The load/store machine's separate loads and stores are exactly the pieces a pipeline can overlap. The register-memory machine's fused instruction cannot overlap its own internal read-modify-write — it is one indivisible lump.

PICTURE.

Top row (register-memory): one fat red lump, ~10 cycles, nothing to hide it behind. Bottom row (load/store): the two loads and one add slide over each other; the second miss tucks partly under the first. The total wall-clock width is what matters, and overlap squeezes the tall column of Step 3.

---

Step 5 — Turning overlap into a number: average CPI

WHAT. Average CPI is total pipeline cycles divided by number of instructions:

${\text{CPI}}_{\text{avg}}=\frac{\text{total pipeline cycles}}{\text{number of instructions}}$

• numerator — the real wall-clock ticks the whole sequence took (after overlap).
• denominator — how many instructions we divided that cost across.

WHY divide. Overlap "shares" the cost of a slow instruction across its neighbours. Dividing captures that sharing as a per-instruction average.

Using the parent's textbook numbers — the overlapped 3-instruction load/store sequence takes 12 cycles, the un-overlappable single fused instruction takes 10:

${\text{CPI}}_{\text{ls}}=\frac{12}{3}=4,{\text{CPI}}_{\text{rm}}=\frac{10}{1}=10$

PICTURE.

The 12 cycles are spread over 3 bars → each bar is only 4 ticks tall. The 10 cycles sit on 1 bar → 10 ticks tall. The red load/store average is lower, precisely because there were more bars to spread across.

---

Step 6 — The master formula: execution time

WHAT. Everything combines into one equation for real time:

$T=I\times \text{CPI}\times T_{\text{clk}}$

• $I$ — instruction count (Step 2).
• $\text{CPI}$ — average cycles per instruction (Step 5).
• $T_{\text{clk}}$ — seconds per clock tick $=1/f_{\text{clk}}$, where $f_{\text{clk}}$ is clock frequency. Simpler instructions → shorter critical path → higher $f_{\text{clk}}$ → smaller $T_{\text{clk}}$.

WHY multiply these three. Time = (how many instructions) × (ticks each) × (seconds per tick). The units cancel cleanly: $\text{instr}\times \frac{\text{cyc}}{\text{instr}}\times \frac{\text{s}}{\text{cyc}}=\text{s}$.

Plug the parent's numbers. Load/store clocks faster ($f=3\text{ GHz}\Rightarrow T_{\text{clk}}=0.33\text{ ns}$); register-memory clocks slower ($f=2.5\text{ GHz}\Rightarrow T_{\text{clk}}=0.4\text{ ns}$):

$T_{\text{rm}}=1\times 10\times 0.4\text{ ns}=4.0\text{ ns}$ $T_{\text{ls}}=3\times 4\times 0.33\text{ ns}\approx 4.0\text{ ns}$

PICTURE.

Watch the three factors trade off. Load/store loses on $I$ (4 vs 1... here shown as the 3 executed steps), but wins on both $\text{CPI}$ and $T_{\text{clk}}$. The two red products land at the same wall-clock height — and in real chips the load/store side dips lower, thanks to better pipelining and out-of-order execution (see Instruction pipelining and Register allocation).

---

Step 7 — The degenerate cases (never leave a gap)

Every claim above must survive its extremes.

Three tiny panels, one per case, each with the red winning bar — proof the conclusion holds across the whole space of inputs, not just the tidy example.

---

The one-picture summary

Read left to right: more bricks ($I\uparrow$) feed into shorter bars ($\text{CPI}\downarrow$ via overlap) feed into a faster tick ($T_{\text{clk}}\downarrow$ via simple decode), and the three multiply to a wall-clock time that is no worse — usually better. The red arrow is the whole thesis of the parent note in one stroke.

Recall Feynman retelling — say it back in plain words

Imagine a chef who may only cook on the counter. Ingredients live in a fridge across the room. Every ingredient must be carried out (a load) and every dish carried back (a store); the chef's knife never reaches into the fridge. A rival chef is allowed to chop straight inside the fridge — one motion instead of three.

You'd guess the rival is faster: fewer motions! But each fridge-reach makes the rival stand and wait for the fridge door, and he can't do anything else while waiting. Our tidy chef, meanwhile, carries the next ingredient out while the last one is being chopped — an assembly line. His motions are more numerous but each is short, predictable, and overlappable, and because his moves are so simple his hands move faster overall.

Total time is (number of motions) × (time per motion) × (speed of hands). The tidy chef loses the first factor and wins the other two — and the product comes out equal or better. That is the entire load/store argument.

Recall Rapid self-check

Why does load/store issue more instructions? ::: Arithmetic touches only registers, so each memory value needs its own explicit LOAD or STORE instruction. What are the three factors in execution time? ::: $I$ (instruction count), $\text{CPI}$ (cycles per instruction), $T_{\text{clk}}$ (seconds per cycle). Why is load/store's CPI lower despite more instructions? ::: A pipeline overlaps its separate loads/stores/ops, so the cost of a slow memory access is shared across neighbours. Why is load/store's $T_{\text{clk}}$ smaller? ::: Simple, uniform instructions give a shorter critical path and simpler decode → higher clock frequency. In the all-cache-hit case, who wins and why? ::: Load/store, because memory penalty disappears and the faster clock decides it.

---

See also: Addressing modes · Instruction encoding · RISC vs CISC philosophy · Instruction pipelining