Load - store architecture model: Worked examples — Hardware deep dive

This page is the "hands dirty" companion to the parent topic. There we argued why a CPU that only touches memory through load and store wins. Here we prove it by grinding through every kind of situation the model can throw at you: single ops, expression trees, register shortages, and the degenerate edge cases (zero memory ops, everything already in registers, a cache miss on every access).

Before line one, three words we will lean on constantly, in plain English:

We also need two measuring sticks, defined before we ever use them:

And three words about registers running out, defined here so the spill example makes sense:

One more word we will need from Example 6 onward — define it now before we lean on it:

The scenario matrix

Every load/store problem is one (or a mix) of the cells below. The worked examples that follow are each tagged with the cell they cover, and together they fill the whole grid.

Figure — Load - store architecture model

Figure 1 — The nine scenario cells laid out as a grid. Cells A–E (blue row, left) vary the shape of the computation, from a single round-trip up to register spilling. Cells F–I (green row, right) vary the cost model applied to it — timing showdown, cache-miss worst case, a word problem, and the exam trap. The whole page is a walk through this grid.

Cell	Situation	What makes it tricky	Example
A	Single memory→register→memory op	The baseline: 1 op needs load + store around it	Ex 1
B	Expression with intermediates	Results must survive in registers between ops	Ex 2
C	Zero memory ops (all in registers)	The best case for load/store; $I$ is minimal	Ex 3
D	More live values than registers	Register spilling — forced extra load/store	Ex 4
E	Immediate (constant) operand	No load needed for a literal number	Ex 5
F	Timing showdown vs register-memory	Compute $T$ on both, find the crossover	Ex 6
G	Degenerate: every access misses cache	Limiting worst-case; where CPI blows up	Ex 7
H	Real-world word problem	Translate English → load/store plan	Ex 8
I	Exam twist: count instructions AND cycles	The trap where "fewer instructions" loses	Ex 9

The worked examples

Example 1 — Cell A: the baseline round-trip

Figure 2 — The baseline round-trip for x = x + 1. The blue arrow (load) carries x out of the memory box on the left into register R2 on the counter; the ALU adds 1 (yellow); the red arrow (store) carries the result back. Two arrows cross the wall = two memory accesses; the add in the middle touches only registers.

Worked example Increment a memory variable:

x = x + 1 R0 holds the address of x. R1 holds the constant 1 already. Write the load/store code and count the memory crossings.

Forecast: guess now — how many instructions? How many memory accesses?

Load x into a register.
```
LW  R2, 0(R0)     # R2 = memory[R0] = x
```
Why this step? The ALU cannot see x while it lives in memory. The only doorway in is a load (blue arrow in Figure 2).
Add on registers.
```
ADD R2, R2, R1    # R2 = x + 1
```
Why this step? Now both operands (R2 and R1) are registers, so the ALU is allowed to touch them.
Store the result back.
```
SW  R2, 0(R0)     # memory[R0] = x + 1
```
Why this step? The new value lives only on the counter (R2). If we never write it back, memory still holds the old x (red arrow in Figure 2).

Answer to the forecast: 3 instructions, and only 2 cross the memory wall. If you guessed "3 memory accesses" you over-counted — the middle ADD never touches memory.

Verify: 3 instructions, exactly 2 memory accesses (1 load + 1 store) — the minimum any read-modify-write of a memory cell can have. A register-memory machine would spell this ADD [x], 1 in 1 instruction, but it still performs the same 2 memory accesses internally. Same wall-crossings, different bookkeeping.

Example 2 — Cell B: intermediates that must live in registers

Figure 3 — Expression tree for (a + b) - c. Leaves a, b, c (blue) are loaded from memory; the inner node a+b (yellow) is an intermediate that has nowhere to live but a register; the root - (red) produces r. Every non-leaf node = one value that must occupy a register until its parent consumes it.

Worked example Evaluate

r = (a + b) - c Addresses: R10=&a, R11=&b, R12=&c, R13=&r. Show why each partial result needs a register.

Forecast: how many registers hold live values at the busiest moment?

Load the inputs.
```
LDR R1, [R10]     # R1 = a
LDR R2, [R11]     # R2 = b
```
Why this step? Two operands of the first + must both be on the counter simultaneously (the two blue leaves in Figure 3).
First add — capture the intermediate.
```
ADD R3, R1, R2    # R3 = a + b   (intermediate!)
```
Why this step? a+b is a temporary (the yellow node). In load/store it has nowhere to hide except a register (R3). This is exactly why these machines carry many registers.
Load c, then subtract.
```
LDR R4, [R12]     # R4 = c
SUB R5, R3, R4    # R5 = (a+b) - c
```
Why this step? c was not needed until now, so we delay its load (giving the scheduler freedom to move it earlier to hide latency).
Store.
```
STR R5, [R13]     # r = result
```

Answer to the forecast: the busiest instant is right after step 3, when R3=(a+b) and R4=c are both live → 2 live values. If you guessed 3 or 4, remember R1 and R2 died the moment their sum landed in R3.

Verify: 3 loads + 1 store + 2 ALU = 6 instructions; 4 memory accesses. Peak live registers: after step 3 we hold R3=(a+b) and R4=c at once → 2 live temporaries. As long as the machine has ≥2 free registers, no spilling happens. Result value: with $a = 5, b = 3, c = 4$ , $r = (5 + 3) - 4 = 4$ . ✓

Example 3 — Cell C: zero memory ops (the best case)

Figure 4 — All operands already resident on the counter. No arrow crosses the memory wall (greyed out on the left); the ALU multiplies R1*R2 then adds R3, entirely register-to-register. This is the cheapest shape a load/store machine can run.

Worked example Everything already in registers:

R6 = R1*R2 + R3 Suppose a compiler has already loaded a→R1, b→R2, c→R3 earlier and will use R6 many times before storing. Compute the fused multiply-add on registers only.

Forecast: how many memory accesses does this cost?

Multiply.
```
MUL R4, R1, R2    # R4 = R1 * R2
```
Why this step? Pure register op — the ALU's home turf, ~1 cycle, perfectly pipelineable.
Add.
```
ADD R6, R4, R3    # R6 = R1*R2 + R3
```

Answer to the forecast: zero memory accesses — nothing crosses the wall (Figure 4). If you guessed any load or store, you were tricked by the operands being variables; here they were already resident.

Verify: 0 loads, 0 stores — the load/store model shines brightest when data is kept resident. With $R 1 = 2, R 2 = 5, R 3 = 7$ : $R 6 = 2 \times 5 + 7 = 17$ . ✓ This is the whole point of having 32 registers: amortise the wall-crossings across many register ops.

Example 4 — Cell D: register pressure and spilling

Now the ugly case. Imagine a toy CPU with only 3 usable registers R1,R2,R3, and we must compute y = a + b + c + d where all four live in memory.

Figure 5 — Streaming accumulation. Time runs left to right across the four steps. The red bar spanning the whole width is register R3, the running sum — it stays live from the first add to the store and is never evicted. The short blue blocks are transient input registers (R1,R2, then R1 reused for c, then R1 reused for d), each appearing only when needed. The green arrow is the punchline: pressure never exceeds 3, so no spill occurs.

Worked example

y = a + b + c + d on a 3-register machine Addresses in R0 (we reuse it as a scratch pointer via offsets: 0(R0)=a, 4(R0)=b, 8(R0)=c, 12(R0)=d, 16(R0)=y).

Forecast: we have 4 inputs but 3 registers. Must something get spilled? Guess how many extra memory accesses a spill would cost.

Load a and b, add.
```
LW  R1, 0(R0)     # R1 = a
LW  R2, 4(R0)     # R2 = b
ADD R3, R1, R2    # R3 = a + b   (running sum lives in R3)
```
Why this step? Keep the running total in R3; that frees R1,R2 to be reused for the next input. This caps the pressure.
Reuse R1 for c, fold it in.
```
LW  R1, 8(R0)     # R1 = c
ADD R3, R3, R1    # R3 = a + b + c
```
Why this step? We only ever need the running total (R3) plus one new input (R1) live at once — pressure = 2, well under our 3 registers. See the red bar staying put while blue R1 cycles.
Reuse R1 for d, fold it in.
```
LW  R1, 12(R0)    # R1 = d
ADD R3, R3, R1    # R3 = a + b + c + d
```
Why this step? Same trick again — stream the last input through R1. The accumulator pattern keeps pressure flat.
Store the total.
```
SW  R3, 16(R0)    # y = total
```
Why this step? The final sum lives only in R3; write it across the memory wall to make it permanent.

Answer to the forecast: with the accumulate-as-you-go ordering, no spill happens — a spill would have cost +2 memory accesses (one store + one reload). If you predicted a forced spill, that only happens under the naive ordering below.

Verify: 4 loads + 1 store = 5 memory accesses; 3 ADDs. Because we streamed the inputs, no spill happened — the accumulator pattern kept us inside 3 registers. If instead we had loaded all four first (a,b,c fill R1,R2,R3, then d has nowhere to go), pressure would hit 4 > 3 → we would spill: store one live value to memory and reload it later — +2 extra memory accesses. With $a, b, c, d = 1, 2, 3, 4$ : $y = 10$ . ✓

Lesson (the whole cell): register pressure is real; smart ordering (accumulate as you go) keeps live values few and avoids spills — precisely the compiler optimisation the parent note mentioned (see Register allocation).

Example 5 — Cell E: immediate operand (no load for constants)

Figure 6 — Where constants live. The variable a (blue) is loaded from the memory box across the wall. The constants 4 and #10 (yellow) ride inside the instruction word itself — shown as small badges attached to the MUL and ADD boxes — so they cost no memory access. Only one arrow crosses the wall inbound, one outbound.

Worked example

z = a * 4 + 10 with constants baked in R0 = &a, result to R0+4.

Forecast: the numbers 4 and 10 live in memory too, right? (Trap.)

Load only the memory variable.
```
LDR R1, [R0]      # R1 = a
```
Why this step? a is data in memory. But 4 and 10 are constants known at compile time.
Multiply by an immediate.
```
MUL R1, R1, #4    # R1 = a * 4   (#4 is baked into the instruction)
```
Why this step? The #4 rides inside the instruction's encoding — no load needed (the yellow badge in Figure 6). A constant is not "in memory," it's part of the program. (See Instruction encoding for where those bits live.)

Add an immediate.

ADD R1, R1, #10   # R1 = a*4 + 10
STR R1, [R0, #4]  # store z

Answer to the forecast: the trap wanted you to load 4 and 10. They are immediates baked into the instruction word, so they cost zero memory accesses — the total is just 1 load + 1 store.

Verify: only 1 load + 1 store = 2 memory accesses, despite three "numbers" appearing. With $a = 5$ : $z = 5 \times 4 + 10 = 30$ . ✓ Immediates are the cheapest operand there is.

Example 6 — Cell F: the timing showdown

This is the crossover the parent note claimed. Let's compute both wall-clock times end to end.

Figure 7 — Cycles as bar height (= CPI). The single red bar is x86's one fused instruction, height 10, because its hidden read-modify-write costs 10 cycles and cannot overlap itself. The three short blue bars are ARM's LDR, ADD, STR, each 4 cycles tall. The yellow arrow marks the key reading: total coloured area is nearly equal, and area (bars × height ≈ total cycles) × $T_{clk}$ = time, so both finish in ~4 ns.

Task: memory[addr] = memory[addr] + R9. Numbers (illustrative, matching the parent note):

x86 (register-memory): 1 instruction, but it fuses read-modify-write → CPI = 10, clock $f = 2.5$ GHz so $T_{clk} = 0.4$ ns.

ARM (load/store): 3 instructions (LDR, ADD, STR), overlap hides one cache miss (the ~10-cycle stall defined above) → CPI = 4, clock $f = 3$ GHz so $T_{clk} \approx 0.33$ ns.

Worked example Same task, two machines:

mem += reg Forecast: which finishes first — or is it a tie?

x86 total time. $T_{x86} = I \times CPI \times T_{clk} = 1 \times 10 \times 0.4 ns = 4.0 ns$ Why this step? Apply the one true scoreboard $T = I \cdot CPI \cdot T_{clk}$ . The single instruction is not free — its CPI of 10 is the hidden read-modify-write that cannot overlap with itself.
ARM total time. $T_{ARM} = 3 \times 4 \times 0.33 ns = 3.96 \approx 4.0 ns$ Why this step? More instructions ( $I = 3$ ) but far lower CPI (4) and a faster clock. The three factors nearly cancel.
Why is ARM's per-instruction CPI only 4, not 10? Why this step? Here is the mechanism the bars hide. On ARM the load, add, and store are separate instructions, so the pipeline can overlap them. Suppose the LDR suffers a cache miss — the ~10-cycle stall we defined earlier. While that LDR is stalled waiting for main memory, the machine can already be fetching and decoding the next instructions, and any independent nearby work keeps issuing into the pipeline. The single ~10-cycle miss is thus spread across the 3-instruction window rather than paid in full for every instruction — averaging out to about 4 cycles per instruction. x86's fused instruction, by contrast, must do read→modify→write inside one instruction, so its 10-cycle latency cannot hide behind anything: CPI stays 10. This overlap is exactly Instruction pipelining at work — and it is only possible because load/store split the memory access into its own instruction.

Answer to the forecast: it is essentially a tie ( $4.0$ ns vs $3.96$ ns), with the edge to load/store. If you guessed "x86 wins, fewer instructions," Figure 7 shows why the equal areas make it a wash.

Verify: $T_{x86} = 4.0$ ns, $T_{ARM} \approx 3.96$ ns → effectively a tie in this toy model, with the edge to load/store once real pipelining hides more of the miss. This confirms the parent's claim: judge by time, not instruction count.

Example 7 — Cell G: degenerate worst case (every access misses)

Figure 8 — The cold-cache limit. Each of the five memory accesses (red blocks) pays the full 10-cycle miss latency with no overlap — the blocks stack end to end because a dependency chain forbids hiding them. The three ALU ops (blue) add just 1 cycle each. The tall red total dwarfs the blue: this is where CPI blows up.

Worked example Cold cache: every load and store misses

Take Example 4's code (y=a+b+c+d, 4 loads + 1 store) but assume a completely cold cache: every one of the 5 memory accesses misses and pays the full 10-cycle latency (the miss cost defined earlier), with no overlap available (data dependencies chain everything). ALU ops cost 1 cycle each; there are 3 ADDs.

Forecast: how bad does CPI get in the limit where nothing hides?

Count total cycles pessimistically. $cycles = memory 5 \times 10 + ALU 3 \times 1 = 50 + 3 = 53$ Why this step? With zero overlap, latencies simply add. This is the upper bound — the limiting behaviour the model must survive.
Average CPI over 8 instructions (5 memory + 3 ALU): $CPI_{worst} = \frac{53}{8} = 6.625$ Why this step? CPI is total cycles ÷ instruction count. Cold caches drag it upward from the ~1 we'd hope for.

Answer to the forecast: CPI climbs all the way to 6.625 in the no-overlap limit — over 6× worse than a warm cache. If you guessed "around 10," remember the three cheap ALU ops pull the average down.

Verify: 53 cycles, CPI $= 6.625$ . Compare with a fully warm cache (every access ~1 cycle): $cycles = 5 \times 1 + 3 \times 1 = 8$ , CPI $= 1.0$ . So the same code spans CPI 1.0 → 6.625 purely from memory behaviour — which is exactly why the load/store model isolates memory ops: so the fast register ops stay predictable while only the loads/stores absorb the variance. (More at Memory hierarchy.)

Example 8 — Cell H: real-world word problem

Figure 9 — Sensor averaging pipeline. Two blue arrows load t1 and t2 from their memory addresses into R1, R2; the ALU adds them (yellow) then shifts right by one bit — a right-shift halves a binary number because every bit slides to a place worth half as much. The red arrow stores the average back to 0x28.

Worked example Sensor averaging

A microcontroller reads two temperature sensors stored at memory 0x20 and 0x24, must compute their average (t1 + t2) / 2, and write it to 0x28. Division by 2 is a right-shift by 1 (LSR ... #1). Base address is in R0. Write it.

Forecast: translate the English into loads, ALU ops, and a store — how many of each?

Load both sensors.
```
LDR R1, [R0, #0x20]   # R1 = t1
LDR R2, [R0, #0x24]   # R2 = t2
```
Why this step? Two independent loads — a scheduler may issue them together (see Addressing modes for the [base, #offset] form used here). Data in memory can only reach the ALU through a load.
Add the two readings.
```
ADD R3, R1, R2        # R3 = t1 + t2
```
Why this step? Both operands are now registers, so the ALU is allowed to add them; the sum lives in R3.
Halve by shifting right one bit.
```
LSR R3, R3, #1        # R3 = (t1 + t2) / 2
```
Why this step? Shifting a binary number right by 1 bit divides it by 2 (each bit's place-value halves) — a pure register op, far cheaper than a full divide instruction.
Store the average back to memory.
```
STR R3, [R0, #0x28]   # memory[0x28] = average
```
Why this step? The result lives only in R3; the store writes it across the memory wall so other code can read it.

Answer to the forecast: 2 loads, 2 ALU ops (add + shift), 1 store. If you forgot the shift counts as an ALU op, you'd have under-counted the register work.

Verify: 2 loads + 1 store = 3 memory accesses; 2 ALU ops. With $t 1 = 20, t 2 = 24$ : sum $= 44$ , $44 ≫ 1 = 22$ = average. ✓ (Integer division truncates: with $t 1 = 21, t 2 = 24$ , sum $= 45$ , $45 ≫ 1 = 22$ , matching $⌊ 45/2 ⌋ = 22$ .)

Example 9 — Cell I: the exam trap (count both, pick the winner)

Figure 10 — The trap visualised. Left: Machine P, only 2 instructions but each very costly (tall red bars, CPI 8). Right: Machine Q, 4 slim instructions (short blue bars, CPI 2) on a clock twice as fast. The green total-time labels reveal the verdict: Q's stack is 4× shorter in real time despite having more bars.

Worked example "Which is faster?" — and it's NOT the one with fewer instructions

Given w = a + b where a, b, w are all in memory:

Machine P (register-memory): does it in 2 instructions, CPI $= 8$ , $T_{clk} = 0.5$ ns.
Machine Q (load/store): does it in 4 instructions (2 LDR, 1 ADD, 1 STR), CPI $= 2$ , $T_{clk} = 0.25$ ns.

Forecast: the exam wants you to blurt "P, fewer instructions!" Resist and compute.

Machine P total time. $T_{P} = I \times CPI \times T_{clk} = 2 \times 8 \times 0.5 ns = 8.0 ns$ Why this step? Never trust $I$ alone — multiply in CPI and $T_{clk}$ . P's two complex instructions carry a high CPI of 8.
Machine Q total time. $T_{Q} = 4 \times 2 \times 0.25 ns = 2.0 ns$ Why this step? Four instructions, but each is simple (low CPI of 2) on a clock twice as fast.
Compare. $\frac{T _{P}}{T _{Q}} = \frac{8.0}{2.0} = 4$ Why this step? The ratio makes the verdict concrete: Q (load/store) wins by 4×, despite having twice the instruction count.

Answer to the forecast: if you blurted "P," the arithmetic refutes you — Q wins by 4× ( $2.0$ ns vs $8.0$ ns). The instruction count was the bait; time is the truth.

Verify: $T_{P} = 8.0$ ns, $T_{Q} = 2.0$ ns, ratio $= 4.0$ . The load/store machine is 4× faster. ✓ This is the exact fallacy dismantled in the parent note's first [!mistake] callout. Relates to the broader RISC vs CISC philosophy.

Recall

Recall Why does an ALU op never name a memory address?

Because in a load/store architecture only load/store instructions touch memory — keeping ALU ops fast, fixed-latency, and easy to pipeline. ::: The ALU can only read/write registers.

Recall The one fair scoreboard for speed

Execution time. ::: $T = I \times CPI \times T_{clk}$ — never instruction count alone.

Recall What makes a value "live", and what is a spill?

Live = already computed and still needed later; a spill = storing a live value to memory (and reloading it) when register pressure exceeds the register count. ::: Spill costs one extra store + one extra load.

Recall Cache hit vs cache miss latency (as used on this page)

Hit ≈ 1 cycle, miss ≈ 10 cycles. ::: The ~10× gap is what makes memory timing variable.

Recall Cold-cache worst-case CPI from Example 7

With 5 misses × 10 cycles + 3 ALU × 1 over 8 instructions. ::: $53/8 = 6.625$ .

Recall Example 9 verdict

Which machine wins and by how much? ::: Load/store machine Q, $T_{Q} = 2$ ns vs $T_{P} = 8$ ns — 4× faster.