Load - store architecture model — Hardware notes

What is a load/store architecture?

WHY this design? Three key reasons:

Uniform instruction timing: Memory access is unpredictable (cache hits/misses). Separating it makes non-memory instructions fast and predictable.
Simplified hardware: The ALU doesn't need memory interface logic. Decode is simpler (fewer instruction formats).
Compiler optimization: Explicit data movement makes register allocation and instruction scheduling easier to optimize.

The alternative: Register-memory architectures

Contrast with x86 (a register-memory architecture):

; x86 can do this:
ADD [memory_addr], EAX    ; Read memory, add EAX, write back
 
; RISC load/store requires:
LDR R1, [memory_addr]     ; Load into register
ADD R1, R1, R2            ; Operate on registers
STR R1, [memory_addr]     ; Store back

WHY x86 seems "better": Fewer instructions! But the x86 ADD hides complexity—it's actually doing 3 operations internally, and its timing varies wildly based on cache behavior.

WHY RISC is actually better:

Each instruction does one thing → pipelining is easier
Predictable timing → easier to meet real-time deadlines
Simpler decode → lower power, higher clock speeds

Formula Instruction count trade-off

Let $N_{\text{ops}}$ = number of operations needed.

Register-memory architecture: $I_{\text{rm}} = N_{\text{ops}} \text{ instructions}$ Load/store architecture: $I_{\text{ls}} = N_{\text{ops}} + N_{\text{loads}} + N_{\text{stores}}$

But load/store wins because: $\text{CPI}_{\text{ls}} \ll \text{CPI}_{\text{rm}}$ (Cycles per instruction is much lower when memory ops are separate)

Performance: $\text{Time} = \frac{I \times \text{CPI}}{f_{\text{clock}}}$

Load/store architectures can push $f_{\text{clock}}$ higher and pipeline more agressively, offseting higher $I$ .

Deriving the performance advantage

Start from first principles:

Execution time = (Number of instructions) × (Cycles per instruction) × (Clock period) $T = I \times \text{CPI} \times T_{\text{clk}}$
Why does CPI differ?
- Register-memory: Each instruction might stall waiting for memory (variable latency)
- Load/store: Memory ops are explicit and isolated, so the pipeline knows exactly when to stall
Example scenario: Add two numbers from memory x86 (register-memory):
```
ADD [0x1000], EAX  ; ~10 cycles if cache miss
```
ARM (load/store):
```
LDR R1, [R0]      ; ~10 cycles if cache miss
ADD R1, R1, R2    ; ~1 cycle (register op)
STR R1, [R0]      ; ~10 cycles if cache miss
```
ARM has 3 instructions vs. 1, but:
- ARM can pipeline the ADD while loads/stores happen
- ARM can reorder independent loads (out-of-order execution easier)
- ARM's simple decoder runs at 3 GHz vs. x86's 2.5 GHz (example numbers)
Working out the average CPI (where does "4" come from?): The two memory ops each cost ~10 cycles on a miss, the ALU op costs ~1 cycle. But those numbers are per-instruction latencies, not the throughput CPI. Because a pipelined machine overlaps these instructions, the effective per-instruction cost is much lower. Let's compute it explicitly.

Assume in steady-state pipelining, a cache miss stalls the pipe but subsequent independent instructions keep issuing. A common textbook approximation is: $\text{CPI}_{\text{avg}} = \frac{\text{total pipeline cycles}}{\text{number of instructions}}$

Suppose the 3-instruction ARM sequence, with overlap, takes 12 pipeline cycles total (one memory miss largely hidden behind the other work, plus base pipeline fill): $\text{CPI}_{\text{ARM}} = \frac{12}{3} = 4 \text{ cycles/instruction}$

For x86, the single fused instruction cannot overlap its internal read-modify-write, so its per-instruction cost stays at the full ~10-cycle latency: $\text{CPI}_{\text{x86}} = \frac{10}{1} = 10 \text{ cycles/instruction}$

This is why load/store's low CPI (4) beats the high CPI (10) of register-memory, even with more instructions.
Net result: $T_{\text{x86}} = 1 \times 10 \times 0.4\text{ns} = 4.0\text{ns}$ $T_{\text{ARM}} = 3 \times 4\times 0.33\text{ns} = 4.0\text{ns}$

(Simplified, but shows the trade-off. In practice, ARM often wins due to better pipelining.)

Worked example Example1: Simple array sum (MIPS-style)

Task: Sum two array elements: c = a[i] + b[i]

# Assume R1 = &a[i], R2 = &b[i], R3 = &c[i]
LW   R4, 0(R1)      # Load a[i] into R4
LW   R5, 0(R2)      # Load b[i] into R5
ADD  R6, R4, R5     # R6 = R4 + R5
SW   R6, 0(R3)      # Store R6 to c[i]

Why this step?

LW (load word): Memory → Register is the only way to get data into the CPU
ADD: ALU can only see registers, never memory
SW (store word): Results must be written back explicitly

Contrast with x86:

MOV EAX, [a+i]      ; Load and operate...
ADD EAX, [b+i]      ; ...can happen in one instruction
MOV [c+i], EAX

x86 uses 3 instructions, MIPS uses 4. But MIPS instructions are simpler → faster clock, easier pipeline.

Worked example Example 2: Register pressure scenario

Task: d = (a + b) * (c + 3)

Load/store (ARM-style):

LDR  R1, [R10]      # Load a
LDR  R2, [R11]      # Load b
ADD  R3, R1, R2     # R3 = a + b
LDR  R4, [R12]      # Load c
ADD  R5, R4, #3     # R5 = c + 3 (immediate)
MUL  R6, R3, R5     # R6 = R3 * R5
STR  R6, [R13]      # Store d

Why this step?

Intermediate results (a+b), (c+3) live in registers between operations
This is why load/store architectures have many registers (32 in MIPS/RISC-V vs. 8 in 32-bit x86)
More registers → less register spilling to memory Register-memory alternative:

MOV  EAX, [a]
ADD  EAX, [b]        ; Result in EAX
MOV  EBX, [c]
ADD  EBX, 3
IMUL EAX, EBX        ; two-operand register multiply (MUL has no 2-operand form)
MOV  [d], EAX

Fewer registers needed, but variable-latency instructions complicate the pipeline.

Note on IMUL vs MUL: x86's MUL is a one-operand instruction that implicitly uses EAX and writes the result across EDX:EAX. To multiply two arbitrary registers into a single register (EAX = EAX * EBX), you must use IMUL EAX, EBX, which does have a two-operand form.

Common mistake Mistake: "Load/store is slower because more instructions"

Why this feels right: 4 instructions > 1 instruction, so it should take longer!

The steel-man argument: If instructions were free, this would be true. A single complex instruction doing load+add+store should beat three separate instructions.

Why it's wrong:

Instructions aren't free: Complex instructions have longer decode times, variable latencies
Clock speed trade-off: Simple instructions → shorter critical path → higher frequency
Pipelining: Load/store splits work into stages that overlap (pipeline paralelism)
Modern CPUs: Out-of-order execution works better with simple, explicit dependencies

The fix: Think in time, not instruction count. Measure: $\text{Performance} = \frac{1}{\text{Execution time}} = \frac{f_{\text{clk}}}{I \times \text{CPI}}$

Recall Explain to a 12-year-old

Imagine you're doing math homework. You have a calculator (the CPU registers) and a backpack full of notes (memory).

Load/store architecture = A strict teacher says: "You can only work with papers on your desk. If you need something from your backpack, take it out first (load). When you're done, put it back (store). You can't do math while reaching into your backpack!"

Register-memory architecture = A relaxed teacher says: "Just grab whatever you need from your backpack and calculate right there."

Why is the strict teacher's rule better? Because:

You work faster when everything is on your desk (registers are 100x faster than memory)
You know exactly when you're reaching into the backpack (predictable timing)
Your desk stays organized (simpler hardware)

The trade-off: You need a bigger desk (more registers) to hold all your papers!

Key characteristics of load/store architectures

1. Instruction format regularity

WHY this matters: Simpler decode logic, faster instruction fetch.

All memory instructions have the same format: $\text{LOAD/STORE} \quad \text{Rdest/Rsrc}, \quad [\text{Rbase} + \text{offset}]$

All ALU instructions: $\text{OP} \quad \text{Rdest}, \quad \text{Rsrc1}, \quad \text{Rsrc2/immediate}$

Contrast x86: Over 1000 instruction variants, variable length (1-15 bytes), complex addressing modes.

2. Large register files

WHY? Since memory isn't directly accessible, you need workspace.

Architecture	Type	Registers
ARMv7 (32-bit)	Load/store	16 registers R0–R15, but only R0–R12 are truly general-purpose (R13=SP, R14=LR, R15=PC are special)
AArch64 (ARM 64-bit)	Load/store	31 general-purpose (X0–X30)
MIPS	Load/store	32 general-purpose
RISC-V	Load/store	32 general-purpose
x86 (32-bit)	Register-memory	8 general (16 in x86-64)

Derivation of register count:

Assume a typical loop body uses:

2-3 array pointers (base addresses)
3-4 loop variables (counters, temporaries)
2-3 intermediate calculation results

Minimum needed: ~8-10 registers.

But for compiler optimization, you want 2-3× this amount so the compiler can:

Unroll loops (need parallel copies of variables)
Keep frequently-used values "alive" across iterations
Avoid "spilling" (writing registers back to memory)

Hence: 32 registers = practical sweet spot (more costs too many encoding bits). This is why the newer AArch64 jumped to 31 GPRs, while the older 32-bit ARMv7 made do with 16 total (of which ~13 are general).

3. Explicit memory ordering

Load/store forces programmers/compilers to think about data movement:

// C code
x = a[i] + b[i];
y = c[i] + d[i];

Compiler must generate:

LDR R1, [a, i]    ; These 4 loads can be
LDR R2, [b, i]    ; reordered by the
LDR R3, [c, i]    ; compiler for optimal
LDR R4, [d, i]    ; cache usage!
ADD R5, R1, R2
ADD R6, R3, R4
STR R5, [x]
STR R6, [y]

In a register-memory ISA, the implicit memory access in ADD [mem], reg hides these optimization opportunities.

Modern reality: Hybrid approaches

Observation: Pure load/store won. Almost all modern high-performance CPUs are load/store:

ARM (phones, Apple M-series, servers)
RISC-V (emerging)
MIPS (legacy embedded)
PowerPC (legacy servers)

But: Even x86 converts internally! Modern x86 CPUs:

Decode complex x86 instructions into simpler micro-ops (μops)
These μops are load/store style
Execute on a RISC-like core

So x86 gets the worst of both worlds: complex decode + load/store execution. This is why ARM is winning in mobile (power efficiency).

Connections

RISC vs CISC philosophy: Load/store is the defining RISC characteristic
Instruction pipelining: Simple instructions enable efficient pipelines
Register allocation: Compilers need many registers for load/store architectures
Memory hierarchy: Explicit loads/stores expose cache behavior to the compiler
Addressing modes: Load/store limits addressing mode complexity
Instruction encoding: Uniform formats save opcode space

Flashcards

What is a load/store architecture? :: An ISA where only load and store instructions access memory, and all arithmetic/logic operations work exclusively on registers. Also called register-register architecture.

Why is load/store architecture faster despite more instructions?

Higher clock frequency (simpler decode) and lower CPI (predictable pipelining) offset the increased instruction count. Performance = I × CPI / f_clock.

What are the three main benefits of load/store architecture?

1) Uniform instruction timing (memory access is isolated), 2) Simplified hardware (ALU doesn't need memory interface), 3) Easier compiler optimization (explicit data movement).

How many general-purpose registers in MIPS vs 32-bit x86?

MIPS has 32 general-purpose registers; 32-bit x86 has 8 (16 in x86-64). Load/store architectures need more registers since memory isn't directly accessible.

Why does the x86 register-register multiply use IMUL not MUL?

MUL is one-operand (implicitly uses EAX, result in EDX:EAX). IMUL has a two-operand form (IMUL EAX, EBX) that multiplies two registers into one destination.

What is register pressure and why does it matter for load/store?

The demand for registers when many intermediate values are needed. Load/store architectures need more registers because all computations must go through registers, not memory.

Why do modern x86 CPUs use micro-ops?

They decode complex x86 instructions into simpler RISC-like micro-ops (load/store style) for execution, getting better pipelining and out-of-order execution.

What is the instruction format for RISC load/store?

LOAD/STORE Rdest/Rsrc, [Rbase + offset] for memory ops; OP Rdest, Rsrc1, Rsrc2 for ALU ops. Uniform formats enable faster decode.

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho, is note ka core idea bahut simple hai - "load/store architecture" ka matlab hai ki CPU sidha memory pe calculation nahi kar sakta. Socho ek chef ki tarah jo sirf apne kitchen counter pe kaam kar sakta hai. Agar usko koi ingredient chahiye to pehle fridge se nikalna padega (yeh hai "load"), phir counter pe kaam karega (arithmetic/logic operations registers pe hote hain), aur kaam khatam hone ke baad wapas fridge mein rakhna padega (yeh hai "store"). Yani sirf load aur store instructions hi memory ko access kar sakte hain, baaki saara calculation sirf registers pe hota hai. RISC-style processors, jaise ARM, isi model ko follow karte hain.

Ab tum sochoge - yeh to zyada instructions lagta hai! x86 (register-memory architecture) mein ek hi ADD instruction memory se data padh sakta hai, calculate kar sakta hai, aur wapas likh sakta hai. Lekin yahan asli baat samajhna zaroori hai: x86 ka woh single instruction andar-andar 3 kaam kar raha hai aur uska timing predict karna mushkil hai (cache hit ya miss ke hisaab se). Jabki load/store mein har instruction ek hi simple kaam karta hai, isliye timing predictable hoti hai. Iska matlab hardware simple ban jaata hai, decode karna aasan hota hai, aur pipelining zyada aggressively ho sakti hai. Formula bhi yahi bolta hai: bhale instruction count $I$ zyada ho, lekin CPI (cycles per instruction) kaafi kam ho jaata hai aur clock frequency $f$ badhayi ja sakti hai.

Yeh baat matter kyun karti hai? Kyunki performance ka final formula hai $Time = \frac{I \times CPI}{f_{clock}}$ . Load/store architecture mein bhale $I$ thoda badh jaaye, lekin kam CPI aur higher clock speed uska poora faayda cover kar deta hai. Isiliye aaj tumhare mobile phones, tablets, aur bahut se modern systems RISC/ARM chips use karte hain - simple, fast, aur power-efficient. Jab tum yeh samajh loge, to tumhe pata chalega ki "kam instructions matlab better" hamesha sach nahi hota - asli game predictability aur pipelining ka hai. Yeh concept computer architecture ka bahut fundamental building block hai, aur aage jab tum pipelining aur processor design padhoge, tab yeh intuition tumhare bahut kaam aayegi.

Load - store architecture model

What is a load/store architecture?

The alternative: Register-memory architectures

Deriving the performance advantage

Key characteristics of load/store architectures

1. Instruction format regularity

2. Large register files

3. Explicit memory ordering

Modern reality: Hybrid approaches

Connections

Flashcards

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Instruction Set Architecture (ISA)

Connections