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

5.1.9 · D3 · Hardware › Instruction Set Architecture (ISA) › Load - store architecture model

Yeh page parent topic ki "haath gande karo" companion hai. Wahan humne argue kiya tha kyun ek CPU jo sirf load aur store ke through memory ko touch karta hai, woh jeetta hai. Yahan hum ise prove karte hain har us situation ko grind karke jo yeh model tumhare saamne rakh sakta hai: single ops, expression trees, register shortages, aur degenerate edge cases (zero memory ops, sab kuch already registers mein, har access pe cache miss).

Pehli line se pehle, teen words jinhe hum constantly use karenge, plain English mein:

Humhe do measuring sticks bhi chahiye, define karte hain pehle se use karne se pehle:

Aur teen words registers khatam hone ke baare mein, yahan define karte hain taaki spill example samajh aaye:

Definition Live values, register pressure, spilling

Ek value program mein kisi point pe live hoti hai agar woh already compute ho chuki ho aur baad mein abhi bhi zaroorat ho. Socho counter pe rakhe ingredients jinhe tumne use nahi kiya abhi tak — unhe phek nahi sakte.
Register pressure = kitni values ek hi moment pe live hain. Agar 5 values live hain par CPU ke paas sirf 4 registers hain, toh pressure capacity se zyada ho jaata hai — counter itne ingredients ke liye chota pad jaata hai.
Spill tab hota hai jab pressure register count se zyada ho jaaye: compiler ko temporarily ek live value ko memory mein store karna padta hai aur baad mein use load karna padta hai. Har spill mein ek extra store + ek extra load lagta hai — exactly wahi wall-crossings jo load/store avoid karne ki koshish karta hai.

Ek aur word jo Example 6 se chahiye hoga — define karo abhi pehle lean karne se pehle:

Scenario matrix

Har load/store problem neeche diye gaye cells mein se ek hai (ya unka mix). Jo worked examples aate hain woh cell ke saath tagged hain, aur milke poora grid cover karte hain.

Figure — Load - store architecture model

Figure 1 — Nau scenario cells ek grid ke roop mein. Cells A–E (blue row, left) computation ki shape vary karte hain, single round-trip se lekar register spilling tak. Cells F–I (green row, right) uss par apply kiya gaya cost model vary karte hain — timing showdown, cache-miss worst case, ek word problem, aur exam trap. Poori page is grid ka walkthrough hai.

Cell	Situation	Kya mushkil hai	Example
A	Single memory→register→memory op	Baseline: 1 op ko load + store chahiye	Ex 1
B	Expression with intermediates	Results ko ops ke beech registers mein survive karna hai	Ex 2
C	Zero memory ops (sab registers mein)	Load/store ke liye best case; $I$ minimal hai	Ex 3
D	Live values zyada registers se	Register spilling — forced extra load/store	Ex 4
E	Immediate (constant) operand	Literal number ke liye koi load nahi chahiye	Ex 5
F	Timing showdown vs register-memory	Dono par $T$ compute karo, crossover nikalo	Ex 6
G	Degenerate: har access cache miss	Limiting worst-case; jahan CPI blow up karta hai	Ex 7
H	Real-world word problem	English → load/store plan mein translate karo	Ex 8
I	Exam twist: instructions AND cycles dono gino	Woh trap jahan "fewer instructions" haarta hai	Ex 9

Worked examples

Example 1 — Cell A: baseline round-trip

Figure 2 — x = x + 1 ke liye baseline round-trip. Blue arrow (load) x ko left ki memory box se register R2 (counter) mein le jaata hai; ALU 1 add karta hai (yellow); red arrow (store) result ko wapas le jaata hai. Ek plus ek = do arrows wall cross karte hain = do memory accesses; beech ka add sirf registers touch karta hai.

Worked example Ek memory variable increment karo:

x = x + 1 R0 mein x ka address hai. R1 mein constant 1 already hai. Load/store code likho aur memory crossings gino.

Forecast: abhi andaaza lagao — kitne instructions? Kitne memory accesses?

x ko register mein load karo.
```
LW  R2, 0(R0)     # R2 = memory[R0] = x
```
Yeh step kyun? ALU x ko tab tak nahi dekh sakta jab tak woh memory mein hai. Andar aane ka ek hi rasta hai — load (Figure 2 mein blue arrow).
Registers par add karo.
```
ADD R2, R2, R1    # R2 = x + 1
```
Yeh step kyun? Ab dono operands (R2 aur R1) registers hain, toh ALU ko inhe touch karne ki ijazat hai.
Result wapas store karo.
```
SW  R2, 0(R0)     # memory[R0] = x + 1
```
Yeh step kyun? Nayi value sirf counter par hai (R2). Agar humne ise wapas nahi likha, memory mein purana x hi rahega (Figure 2 mein red arrow).

Forecast ka jawab: 3 instructions, aur sirf 2 memory wall cross karte hain. Agar tumne "3 memory accesses" guess kiya toh tumne over-count kiya — middle ADD kabhi memory touch nahi karta.

Verify: 3 instructions, exactly 2 memory accesses (1 load + 1 store) — kisi bhi memory cell ke read-modify-write ke liye yeh minimum hai. Ek register-memory machine ise ADD [x], 1 mein 1 instruction mein spell karti, lekin internally wahi 2 memory accesses perform karti. Same wall-crossings, alag bookkeeping.

Example 2 — Cell B: intermediates jo registers mein rehne chahiye

Figure 3 — (a + b) - c ka expression tree. Leaves a, b, c (blue) memory se load hote hain; inner node a+b (yellow) ek intermediate hai jiske rehne ki jagah sirf register hai; root - (red) r produce karta hai. Har non-leaf node = ek value jo register mein tab tak rehni chahiye jab tak uska parent use nahi kar leta.

Worked example

r = (a + b) - c evaluate karo Addresses: R10=&a, R11=&b, R12=&c, R13=&r. Batao har partial result ko register kyun chahiye.

Forecast: sabse busy moment par kitni live values registers mein hoti hain?

Inputs load karo.
```
LDR R1, [R10]     # R1 = a
LDR R2, [R11]     # R2 = b
```
Yeh step kyun? Pehle + ke dono operands ek saath counter par hone chahiye (Figure 3 mein do blue leaves).
Pehla add — intermediate capture karo.
```
ADD R3, R1, R2    # R3 = a + b   (intermediate!)
```
Yeh step kyun? a+b ek temporary hai (yellow node). Load/store mein iske chhupne ki koi jagah nahi siwaaye register (R3) ke. Isliye in machines ke paas kaafi zyada registers hote hain.
c load karo, phir subtract karo.
```
LDR R4, [R12]     # R4 = c
SUB R5, R3, R4    # R5 = (a+b) - c
```
Yeh step kyun? c ki zaroorat abhi tak nahi thi, isliye hum iska load delay karte hain (scheduler ko freedom dete hain ki woh ise pehle move kare latency hide karne ke liye).
Store karo.
```
STR R5, [R13]     # r = result
```

Forecast ka jawab: sabse busy moment step 3 ke baad hai, jab R3=(a+b) aur R4=c dono live hain → 2 live values. Agar tumne 3 ya 4 guess kiya, yaad raho R1 aur R2 jaise hi unka sum R3 mein aaya, woh khatam ho gaye.

Verify: 3 loads + 1 store + 2 ALU = 6 instructions; 4 memory accesses. Peak live registers: step 3 ke baad hum R3=(a+b) aur R4=c ek saath hold karte hain → 2 live temporaries. Jab tak machine ke paas ≥2 free registers hain, koi spilling nahi hoti. Result value: $a = 5, b = 3, c = 4$ ke saath, $r = (5 + 3) - 4 = 4$ . ✓

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

Figure 4 — Sab operands already counter par hain. Koi arrow memory wall cross nahi karta (left par greyed out); ALU R1*R2 multiply karta hai phir R3 add karta hai, purely register-to-register. Yeh woh sabse sasta shape hai jis par ek load/store machine chal sakti hai.

Worked example Sab kuch already registers mein hai:

R6 = R1*R2 + R3 Maano compiler ne pehle se hi a→R1, b→R2, c→R3 load kar liye hain aur R6 ko store karne se pehle kaafi baar use karega. Sirf registers pe fused multiply-add compute karo.

Forecast: isme kitne memory accesses lagte hain?

Multiply karo.
```
MUL R4, R1, R2    # R4 = R1 * R2
```
Yeh step kyun? Pure register op — ALU ka home turf, ~1 cycle, perfectly pipelineable.
Add karo.
```
ADD R6, R4, R3    # R6 = R1*R2 + R3
```

Forecast ka jawab: zero memory accesses — kuch bhi wall cross nahi karta (Figure 4). Agar tumne koi load ya store guess kiya, toh tum operands ke variables hone se trick mein aa gaye; yahan woh already resident the.

Verify: 0 loads, 0 stores — load/store model tab sabse zyada shine karta hai jab data resident rakha jaata hai. $R 1 = 2, R 2 = 5, R 3 = 7$ ke saath: $R 6 = 2 \times 5 + 7 = 17$ . ✓ 32 registers rakhne ka yahi point hai: wall-crossings ko kai register ops mein amortise karo.

Example 4 — Cell D: register pressure aur spilling

Ab ka ugly case. Socho ek toy CPU jisme sirf 3 usable registers R1,R2,R3 hain, aur humhe y = a + b + c + d compute karna hai jahan chaaon memory mein hain.

Figure 5 — Streaming accumulation. Time left se right tak chaar steps mein chalta hai. Red bar jo poori width pe faila hua hai woh register R3 hai, running sum — yeh pehle add se store tak live rehta hai aur kabhi evict nahi hota. Chhote blue blocks transient input registers hain (R1,R2, phir R1 reused for c, phir R1 reused for d), har ek sirf tab aata hai jab zaroorat ho. Green arrow punchline hai: pressure kabhi 3 se zyada nahi hoti, isliye koi spill nahi hota.

Worked example 3-register machine par

y = a + b + c + d R0 mein addresses hain (hum ise scratch pointer ki tarah offsets ke saath reuse karte hain: 0(R0)=a, 4(R0)=b, 8(R0)=c, 12(R0)=d, 16(R0)=y).

Forecast: hamare paas 4 inputs hain par 3 registers. Kya kuch spill hoga? Guess karo ek spill mein kitne extra memory accesses lagte.

a aur b load karo, add karo.
```
LW  R1, 0(R0)     # R1 = a
LW  R2, 4(R0)     # R2 = b
ADD R3, R1, R2    # R3 = a + b   (running sum R3 mein rehta hai)
```
Yeh step kyun? Running total ko R3 mein rakho; yeh R1,R2 ko free kar deta hai taaki unhe agले input ke liye reuse kiya ja sake. Yeh pressure cap karta hai.
R1 ko c ke liye reuse karo, fold karo.
```
LW  R1, 8(R0)     # R1 = c
ADD R3, R3, R1    # R3 = a + b + c
```
Yeh step kyun? Humhe ek waqt sirf running total (R3) aur ek naya input (R1) live chahiye — pressure = 2, hamare 3 registers se kaafi kam. Dekho red bar stable rehta hai jab blue R1 cycle karta hai.
R1 ko d ke liye reuse karo, fold karo.
```
LW  R1, 12(R0)    # R1 = d
ADD R3, R3, R1    # R3 = a + b + c + d
```
Yeh step kyun? Wahi trick phir — last input ko R1 se stream karo. Accumulator pattern pressure ko flat rakhta hai.
Total store karo.
```
SW  R3, 16(R0)    # y = total
```
Yeh step kyun? Final sum sirf R3 mein hai; ise memory wall ke paar write karo taaki permanent ho jaaye.

Forecast ka jawab: accumulate-as-you-go ordering ke saath, koi spill nahi hoti — ek spill mein +2 memory accesses ka cost aata (ek store + ek reload). Agar tumne forced spill predict kiya, woh sirf naive ordering mein hota jo neeche bataya gaya hai.

Verify: 4 loads + 1 store = 5 memory accesses; 3 ADDs. Kyunki humne inputs stream kiye, koi spill nahi hua — accumulator pattern ne hume 3 registers ke andar rakha. Agar uski jagah humne pehle chaaon load kiye hote (a,b,c ne R1,R2,R3 fill kar diya, phir d ke liye koi jagah nahi), pressure 4 > 3 ho jaati → hume spill karna padta: ek live value ko memory mein store karo aur baad mein reload karo — +2 extra memory accesses. $a, b, c, d = 1, 2, 3, 4$ ke saath: $y = 10$ . ✓

Lesson (poora cell): register pressure real hai; smart ordering (accumulate as you go) live values kam rakhti hai aur spills avoid karti hai — exactly woh compiler optimisation jo parent note ne mention kiya tha (dekho Register allocation).

Example 5 — Cell E: immediate operand (constants ke liye koi load nahi)

Figure 6 — Constants kahan rehte hain. Variable a (blue) memory box se wall ke paar load hota hai. Constants 4 aur #10 (yellow) instruction word ke andar hi ride karte hain — MUL aur ADD boxes se attached small badges ke roop mein dikhaye gaye hain — isliye inhe koi memory access nahi lagti. Sirf ek arrow wall ke andar aata hai, ek bahar jaata hai.

Worked example

z = a * 4 + 10 baked-in constants ke saath R0 = &a, result R0+4 par.

Forecast: numbers 4 aur 10 memory mein rehte hain na? (Trap.)

Sirf memory variable load karo.
```
LDR R1, [R0]      # R1 = a
```
Yeh step kyun? a memory mein data hai. Lekin 4 aur 10 compile time par jaane jaate constants hain.
Immediate se multiply karo.
```
MUL R1, R1, #4    # R1 = a * 4   (#4 instruction mein baked hai)
```
Yeh step kyun? #4 instruction ki encoding ke andar ride karta hai — koi load nahi chahiye (Figure 6 mein yellow badge). Constant "memory mein" nahi hota, yeh program ka hissa hai. (Dekho Instruction encoding jahan woh bits rehte hain.)

Immediate add karo.

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

Forecast ka jawab: trap chahta tha ki tum 4 aur 10 load karo. Yeh immediates hain jo instruction word mein baked hain, isliye inhe zero memory accesses lagte hain — total sirf 1 load + 1 store hai.

Verify: sirf 1 load + 1 store = 2 memory accesses, teen "numbers" appear hone ke bawajood. $a = 5$ ke saath: $z = 5 \times 4 + 10 = 30$ . ✓ Immediates sabse saste operand hain.

Example 6 — Cell F: timing showdown

Yahi woh crossover hai jo parent note ne claim kiya tha. Chalo dono wall-clock times end to end compute karte hain.

Figure 7 — Cycles as bar height (= CPI). Single red bar x86 ka ek fused instruction hai, height 10, kyunki uska hidden read-modify-write 10 cycles leta hai aur khud se overlap nahi ho sakta. Teen chhote blue bars ARM ke LDR, ADD, STR hain, har ek 4 cycles tall. Yellow arrow key reading mark karta hai: total coloured area lagbhag equal hai, aur area (bars × height ≈ total cycles) × $T_{clk}$ = time, isliye dono ~4 ns mein khatam hote hain.

Task: memory[addr] = memory[addr] + R9. Numbers (illustrative, parent note se match karte hue):

x86 (register-memory): 1 instruction, lekin yeh read-modify-write fuse karta hai → CPI = 10, clock $f = 2.5$ GHz isliye $T_{clk} = 0.4$ ns.

ARM (load/store): 3 instructions (LDR, ADD, STR), overlap ek cache miss (~10-cycle stall jo upar define kiya) hide karta hai → CPI = 4, clock $f = 3$ GHz isliye $T_{clk} \approx 0.33$ ns.

Worked example Same task, do machines:

mem += reg Forecast: kaun pehle khatam hota hai — ya tie hai?

x86 total time. $T_{x86} = I \times CPI \times T_{clk} = 1 \times 10 \times 0.4 ns = 4.0 ns$ Yeh step kyun? Ek sach scoreboard $T = I \cdot CPI \cdot T_{clk}$ apply karo. Ek instruction free nahi hai — uska CPI 10 woh hidden read-modify-write hai jo khud se overlap nahi ho sakta.
ARM total time. $T_{ARM} = 3 \times 4 \times 0.33 ns = 3.96 \approx 4.0 ns$ Yeh step kyun? Zyada instructions ( $I = 3$ ) lekin kaafi kam CPI (4) aur faster clock. Teeno factors lagbhag cancel ho jaate hain.
ARM ka per-instruction CPI sirf 4 kyun hai, 10 nahi? Yeh step kyun? Yaha woh mechanism hai jo bars hide karte hain. ARM par load, add, aur store alag instructions hain, isliye pipeline inhe overlap kar sakti hai. Maano LDR ko ek cache miss hoti hai — woh ~10-cycle stall jo humne pehle define kiya. Jab woh LDR main memory ka wait karke stall hai, machine already agले instructions fetch aur decode kar sakti hai, aur koi bhi independent nearby work pipeline mein issue hota rehta hai. Ek ~10-cycle miss is tarah 3-instruction window mein faili hoti rather than har instruction ke liye poori poori pay karne ke bajaaye — average out ho jaata hai lagbhag 4 cycles per instruction. x86 ka fused instruction, contrariwise, read→modify→write ek instruction ke andar karna hi padta hai, isliye uska 10-cycle latency kisi cheez ke peechhe hide nahi ho sakta: CPI 10 rehta hai. Yahi overlap exactly Instruction pipelining hai — aur yeh tabhi possible hai jab load/store ne memory access ko apne instruction mein split kiya.

Forecast ka jawab: yeh basically ek tie hai ( $4.0$ ns vs $3.96$ ns), load/store ki thodi edge ke saath. Agar tumne "x86 jeetta, fewer instructions" guess kiya, Figure 7 dikhata hai kyun equal areas ise wash banate hain.

Verify: $T_{x86} = 4.0$ ns, $T_{ARM} \approx 3.96$ ns → is toy model mein effectively tie, load/store ke faavur mein ek baar real pipelining aur miss zyada hide ho. Yeh parent ke claim ko confirm karta hai: time se judge karo, instruction count se nahi.

Example 7 — Cell G: degenerate worst case (har access miss karta hai)

Figure 8 — Cold-cache limit. Paanch mein se har memory access (red blocks) full 10-cycle miss latency pay karta hai bina kisi overlap ke — blocks end to end stack hote hain kyunki dependency chain unhe hide hone se rokti hai. Teen ALU ops (blue) sirf 1 cycle each add karte hain. Tall red total blue ko dwarf karta hai: yahan CPI blow up karta hai.

Worked example Cold cache: har load aur store miss karta hai

Example 4 ka code lo (y=a+b+c+d, 4 loads + 1 store) lekin maano ek completely cold cache: paanch mein se har ek memory access miss karti hai aur full 10-cycle latency (miss cost jo pehle define kiya) pay karti hai, koi overlap nahi hai (data dependencies sab kuch chain kar deti hain). ALU ops 1 cycle lagti hain; 3 ADDs hain.

Forecast: jab kuch bhi hide nahi hota, CPI kitna kharab ho jaata hai?

Total cycles pessimistically gino. $cycles = memory 5 \times 10 + ALU 3 \times 1 = 50 + 3 = 53$ Yeh step kyun? Zero overlap ke saath, latencies simply add ho jaati hain. Yeh upper bound hai — woh limiting behaviour jo model ko survive karna hai.
8 instructions par average CPI (5 memory + 3 ALU): $CPI_{worst} = \frac{53}{8} = 6.625$ Yeh step kyun? CPI = total cycles ÷ instruction count. Cold caches ise ~1 se upar drag karte hain.

Forecast ka jawab: CPI no-overlap limit mein 6.625 tak chadh jaata hai — warm cache se 6× zyada bura. Agar tumne "around 10" guess kiya, yaad raho teen saste ALU ops average ko neeche kheenchte hain.

Verify: 53 cycles, CPI $= 6.625$ . Compare karo fully warm cache se (har access ~1 cycle): $cycles = 5 \times 1 + 3 \times 1 = 8$ , CPI $= 1.0$ . Toh same code CPI 1.0 → 6.625 tak span karta hai purely memory behaviour ki wajah se — jo exactly isliye hai ki load/store model memory ops ko isolate karta hai: taaki fast register ops predictable rahein jabki sirf loads/stores variance absorb karein. (Aur dekho Memory hierarchy.)

Example 8 — Cell H: real-world word problem

Figure 9 — Sensor averaging pipeline. Do blue arrows t1 aur t2 ko unke memory addresses se R1, R2 mein load karte hain; ALU unhe add karta hai (yellow) phir ek bit right shift karta hai — right-shift binary number ko half karta hai kyunki har bit ek aisi jagah pe slide ho jaati hai jiska worth half hai. Red arrow average ko 0x28 par wapas store karta hai.

Worked example Sensor averaging

Ek microcontroller do temperature sensors padhta hai jo memory 0x20 aur 0x24 par stored hain, unka average (t1 + t2) / 2 compute karna hai, aur 0x28 par write karna hai. 2 se division ek right-shift hai (LSR ... #1 se). Base address R0 mein hai. Likho.

Forecast: English ko loads, ALU ops, aur ek store mein translate karo — kitne kitne?

Dono sensors load karo.
```
LDR R1, [R0, #0x20]   # R1 = t1
LDR R2, [R0, #0x24]   # R2 = t2
```
Yeh step kyun? Do independent loads — ek scheduler inhe saath issue kar sakta hai (dekho Addressing modes [base, #offset] form ke liye jo yahan use hoti hai). Memory mein data sirf load ke through ALU tak pahunch sakta hai.
Dono readings add karo.
```
ADD R3, R1, R2        # R3 = t1 + t2
```
Yeh step kyun? Dono operands ab registers hain, isliye ALU ko inhe add karne ki ijazat hai; sum R3 mein rehta hai.
Ek bit right shift karke half karo.
```
LSR R3, R3, #1        # R3 = (t1 + t2) / 2
```
Yeh step kyun? Binary number ko 1 bit right shift karna use 2 se divide karta hai (har bit ki place-value half ho jaati hai) — ek pure register op, full divide instruction se kaafi sasta.
Average wapas memory mein store karo.
```
STR R3, [R0, #0x28]   # memory[0x28] = average
```
Yeh step kyun? Result sirf R3 mein hai; store use memory wall ke paar write karta hai taaki doosra code use padh sake.

Forecast ka jawab: 2 loads, 2 ALU ops (add + shift), 1 store. Agar tum shift ko ALU op count karna bhool gaye, tumne register work under-count kiya hota.

Verify: 2 loads + 1 store = 3 memory accesses; 2 ALU ops. $t 1 = 20, t 2 = 24$ ke saath: sum $= 44$ , $44 ≫ 1 = 22$ = average. ✓ (Integer division truncate karta hai: $t 1 = 21, t 2 = 24$ ke saath, sum $= 45$ , $45 ≫ 1 = 22$ , jo $⌊ 45/2 ⌋ = 22$ se match karta hai.)

Example 9 — Cell I: exam trap (dono gino, winner chuno)

Figure 10 — Trap visualised. Left: Machine P, sirf 2 instructions lekin har ek bahut costly hai (tall red bars, CPI 8). Right: Machine Q, 4 slim instructions (chhote blue bars, CPI 2) clock par jo do guna fast hai. Green total-time labels verdict reveal karte hain: Q ka stack real time mein 4× chota hai zyada bars hone ke bawajood.

Worked example "Kaun tez hai?" — aur woh wala nahi jo fewer instructions rakhta hai

w = a + b jahan a, b, w sab memory mein hain:

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

Forecast: exam chahta hai ki tum "P, fewer instructions!" bol do. Ruko aur compute karo.

Machine P total time. $T_{P} = I \times CPI \times T_{clk} = 2 \times 8 \times 0.5 ns = 8.0 ns$ Yeh step kyun? Kabhi $I$ par akele trust mat karo — CPI aur $T_{clk}$ multiply karo. P ke do complex instructions ka high CPI of 8 hai.
Machine Q total time. $T_{Q} = 4 \times 2 \times 0.25 ns = 2.0 ns$ Yeh step kyun? Chaar instructions, lekin har ek simple hai (low CPI of 2) ek clock par jo do guna fast hai.
Compare karo. $\frac{T _{P}}{T _{Q}} = \frac{8.0}{2.0} = 4$ Yeh step kyun? Ratio verdict ko concrete banata hai: Q (load/store) 4× se jeetta hai, do gune instruction count ke bawajood.

Forecast ka jawab: agar tumne "P" bola, arithmetic tumhe refute karta hai — Q 4× se jeetta hai ( $2.0$ ns vs $8.0$ ns). Instruction count bait tha; time sach hai.

Verify: $T_{P} = 8.0$ ns, $T_{Q} = 2.0$ ns, ratio $= 4.0$ . Load/store machine 4× tez hai. ✓ Yahi woh exact fallacy hai jo parent note ke pehle [!mistake] callout mein dismantled ki gayi thi. Broader RISC vs CISC philosophy se relate karta hai.

Recall

Recall ALU op kabhi memory address kyun nahi name karta?

Kyunki load/store architecture mein sirf load/store instructions memory touch karte hain — ALU ops ko fast, fixed-latency, aur pipeline mein easy rakhte hain. ::: ALU sirf registers read/write kar sakta hai.

Recall Speed ke liye ek fair scoreboard

Execution time. ::: $T = I \times CPI \times T_{clk}$ — kabhi sirf instruction count se nahi.

Recall Value "live" kab hoti hai, aur spill kya hai?

Live = already computed aur abhi bhi baad mein zaroorat hai; spill = ek live value ko memory mein store karna (aur reload karna) jab register pressure register count se zyada ho jaaye. ::: Spill mein ek extra store + ek extra load lagta hai.

Recall Cache hit vs cache miss latency (is page par use hoti)

Hit ≈ 1 cycle, miss ≈ 10 cycles. ::: ~10× gap hi memory timing ko variable banata hai.

Recall Example 7 se cold-cache worst-case CPI

5 misses × 10 cycles + 3 ALU × 1 cycle, 8 instructions par. ::: $53/8 = 6.625$ .

Recall Example 9 verdict

Kaun si machine jeetti hai aur kitne se? ::: Load/store machine Q, $T_{Q} = 2$ ns vs $T_{P} = 8$ ns — 4× faster.