Before we start, here are the words and symbols this whole page leans on. Read them once and the traps below will make sense.
The picture above is the mental model behind almost every trap: a walled-off CPU where the only doors to memory are labelled load and store, and the ALU works purely on the countertop of registers.
Now the two performance words, because half the traps compare speed.
Where does the performance formula come from? Build it from raw units, no memorising:
The figure below is that same cancellation drawn out — read it left to right and watch the "instruction" and "cycle" units annihilate their partners, leaving only seconds in the coral box at the bottom. Whenever a trap tempts you to "just count instructions", picture this: instruction count is only the first box of three.
Finally, the word that explains why simpler instructions can tick faster:
Compare the two rows in the next figure. The top row is a simple load/store instruction: in → decode → ALU, a short coral double-arrow, so the tick can be brief. The bottom row is a would-be fused read-modify-write: in → decode → memory read → ALU, and that extra "memory read" stage stretches the coral double-arrow much longer, forcing a slower tick. The takeaway you carry into the traps: adding stages to one instruction lengthens the critical path and drags Tclk up for every instruction.
Before the number-heavy trap, we need one more idea the parent note leaned on without drawing: how a pipeline hides a slow memory miss.
Read the figure like a calendar of cycles. The load (lavender) stalls for many cycles waiting on memory, but the independent ADD and the second load (mint) slide into those idle cycles instead of waiting their turn. Total wall-clock cycles ≈12 for 3 instructions gives an average of 4 cycles each — this is exactly the ≈12/3 = 4 the parent quoted, and it is why "one load costs 10 cycles" does not mean "CPI must be 10".
In a load/store ISA, the ADD instruction can take a memory address as one operand
False — the whole point is that ALU instructions see only registers; the address would first need a separate load. Allowing it would recreate the register-memory model you were trying to avoid.
A load/store program always runs faster than an equivalent register-memory program
False — it usually has more instructions; it wins on total time only because lower CPI and higher clock speed outweigh the extra instruction count, not in every single case.
Load and store are the only instructions in a load/store ISA that produce a memory address
True — by definition memory is a "walled garden"; every trip in or out of RAM is an explicit load or store, so those are the only address-generating operations.
"Register-register architecture" and "load/store architecture" name two different things
False — they are two names for the same design; "register-register" describes that ALU ops take register sources and a register destination.
Because loads take ~10 cycles on a cache miss, a load/store CPU's average CPI must be about 10
False — that ~10 is a latency of one instruction, not the throughput CPI; pipeline overlap slides independent work into the stall, so the average CPI comes out much lower (≈4 in the parent's example).
x86 needing fewer instructions proves it decodes faster too
False — fewer instructions but each is more complex; a register-memory ADD hides a read-modify-write, giving it a longer decode and variable latency, which is exactly what caps its clock speed.
Having 32 registers instead of 8 is just a marketing number with no real effect
False — more registers let intermediate results like (a+b) and (c+3) live on-chip instead of being spilled back to slow memory, which is what makes load/store's explicit-data-movement style pay off.
Store instructions read a value from a register and write it to memory
True — a store moves register → memory; it is the mirror of a load, and it is the only way a computed result re-enters RAM.
ADD R3, [R1], R2 ; add memory at R1 to R2 — what's wrong in a load/store ISA?
The [R1] memory operand is illegal here; you must LDR R4, [R1] first, then ADD R3, R4, R2. ALU inputs are registers only.
Someone claims MIPS for c = a[i] + b[i] needs the same instruction count as x86 — where's the slip?
MIPS needs 4 (two loads, one add, one store) versus real x86's 3 (MOV, ADD-from-memory, MOV — x86 can't read two memory operands in one instruction either); the extra explicit loads/stores are the visible cost of the walled-garden rule.
STR R6, R3 ; store R6 into R3 — spot the misuse
A store needs a memory address, written [R3], not a bare register; STR R6, R3 is either a syntax error or misread as register-to-register (which stores don't do).
"Merge LDR R1,[R0]; ADD R2,R1,R3 into one fused ADD R2,[R0],R3 to save a cycle." Why is this the wrong optimization for the ISA?
The fused form would need a new encoding, could stall the whole pipeline on a cache miss, and breaks the ISA's regularity — the compiler instead hides latency by reordering the independent load earlier.
x86's MUL EAX, EBX is used to compute EAX = EAX * EBX — what's the error?
MUL is a one-operand instruction that implicitly uses EAX and writes EDX:EAX; to multiply two named registers into one you must use the two-operand IMUL EAX, EBX.
A student writes ADD R1, R1, [mem] "because immediates are allowed, so memory should be too." Where's the confused reasoning?
An immediate is a constant baked into the instruction word, needing no memory trip; a memory operand needs an actual RAM access, which is precisely what ALU instructions forbid — the two are not the same kind of operand.
Why does isolating memory access into just loads and stores make other instructions faster and more predictable?
Because non-memory instructions can never touch the unpredictable cache, their timing is fixed and known, so the pipeline can schedule them without guessing about cache hits or misses.
Why can a load/store CPU often clock higher than a register-memory one?
Its simple, single-purpose instructions have a shorter critical path (less logic per stage), and a shorter critical path lets the clock period Tclk drop, i.e. the frequency fclk rise.
Why does the parent's example give CPI ≈ 4 for ARM but 10 for x86 when both hit the same slow memory?
ARM's three separate instructions let the pipeline overlap the memory miss with the independent ADD, spreading ≈12 cycles over 3 instructions; the parent's modelled x86 read-modify-write step can't overlap its internal read → modify → write, so its ≈10 cycles land on that one step.
Why do load/store ISAs typically provide many registers?
Because intermediate results must live in registers between operations (the ALU can't stash them in memory mid-computation), so more registers mean fewer costly spills to RAM.
Why is out-of-order execution easier on a load/store machine?
Dependencies are explicit and simple — each instruction does one thing with named registers — so the hardware can clearly see which instructions are independent and reorder them safely.
Why is "count instructions" the wrong way to compare the two philosophies?
Performance is governed by T=I×CPI×Tclk; instruction count I is only one of three factors, and load/store trades a higher I for lower CPI and shorter Tclk.
Does adding an immediate constant (ADD R5, R4, #3) violate the "registers only" rule?
No — the constant lives inside the instruction encoding itself, not in memory, so no memory access happens; ALU inputs are still effectively register-or-baked-in, never a memory address.
If a program uses no memory at all (purely register data), how many loads/stores does it need?
Zero — the load/store rule only mandates that memory access goes through loads and stores; if you never touch memory, none are required, and the formula's Nloads+Nstores term is 0.
What happens to load/store's advantage if there are more registers than the program needs (no spilling)?
The advantage is at its strongest: with no register pressure, every intermediate stays on-chip, so you pay only for essential loads/stores and reap the low-CPI, high-clock benefits fully.
In the degenerate case of a program that is all memory traffic (every value used once), does load/store still help?
Its edge shrinks because you can't amortize a loaded value across many ALU ops — but both machines are now bottlenecked by the same number of memory accesses (each value's one read/write), so per-access cost decides it; load/store's shorter critical path still lets it clock those accesses out at least as fast, and pipelining successive independent loads/stores overlaps their stall cycles, so it does not fall behind register-memory on the same memory-bound workload.
Is a program with only one instruction, ADD R1, R2, R3, a valid load/store program even though it never loads or stores?
Yes — "load/store architecture" describes what the ISA permits (memory only via load/store), not a requirement that every program actually use memory; a memory-free program is perfectly legal.
If two loads target the same address back-to-back, may the CPU reorder or drop one?
Only if the memory consistency model permits it (see the definition below) — dropping a redundant load is unsafe when another core or device might have written that address in between, so hardware reuses a value only when it can prove no intervening write occurred.
Recall Quick self-test
What do the three symbols in T=I×CPI×Tclk stand for? ::: I = number of instructions, CPI = cycles per instruction, Tclk = clock period (seconds per tick); their product is total execution time in seconds.
The single biggest reframe on this page? ::: Compare time (T=I×CPI×Tclk), never raw instruction count — load/store trades more instructions for lower CPI and higher clock.
