Superscalar — multiple execution units

4.1.23 · Coding › Computer Architecture (Deep)

WHAT is it?

WHY does it exist? (first-principles)

Ek single-issue 5-stage pipeline zyada se zyada ek instruction per cycle finish kar sakti hai. Lekin real code mein aisi instructions hoti hain jo ek-doosre par depend nahi karti. Example:

a = b + c     // uses b, c
d = e + f     // uses e, f  — independent of line 1!

Agar do adders idle baithein, toh hum silicon waste kar rahe hain. Puri motivation yeh hai: transistors saste hain, time keemti hai — functional units replicate karo aur independent kaam simultaneously chalao.

HOW: deriving the performance model from scratch

Universal CPU performance equation se shuru karte hain. Hum ise derive karte hain, quote nahi.

Ek program run karne ka time = (instructions ki sankhya) × (time per instruction).

$T=N_{\text{inst}}\times \text{CPI}\times T_{\text{cycle}}$

jahan $N_{\text{inst}}$ = dynamic instruction count, $\text{CPI}$ = average Cycles Per Instruction, $T_{\text{cycle}}$ = clock period. Ab CPI ko invert karo:

$\text{IPC}=\frac{1}{\text{CPI}}⟹T=\frac{N_{\text{inst}}{T}_{\text{cycle}}}{\text{IPC}}$

Yeh kyun matter karta hai: ek superscalar machine IPC term ko attack karti hai. Ek scalar pipeline IPC ko 1 par cap karti hai; ek N-wide superscalar ceiling ko N tak raise karta hai. Toh:

Hum IPC = N rarely kyun achieve karte hain (Amdahl-flavoured reasoning)

Maano fraction $p$ instructions perfectly N units mein parallelize ho sakti hain, aur fraction $(1-p)$ serially chalani padti hain (chained dependencies). Tab effective IPC bounded hai:

${\text{IPC}}_{\text{eff}}=\frac{1}{(1-p)+\frac{p}{N}}$

Teen obstacles (aur superscalars unse kaise ladte hain)

Weapons:

• Register renaming false dependencies (WAR, WAW) hatata hai ek hi architectural register name ko alag physical registers se map karke.
• Out-of-order execution + Reorder Buffer (ROB) ready instructions ko stalled walon ko overtake karne deta hai, phir correctness ke liye order mein retire karta hai.
• Branch prediction + speculation units ko branches ke baad bhi fed rakhta hai.
• Multiple ports register file/caches par structural hazards khatam karte hain.

Worked Example 1 — cycles count karna, in-order, 2-wide

Code (har op 1 cycle leta hai, latency 1):

I1: r1 = r2 + r3
I2: r4 = r5 + r6     (independent of I1)
I3: r7 = r1 + r4     (needs r1 from I1, r4 from I2)
I4: r8 = r9 + r10    (independent)

2-wide, in-order, do integer ALUs.

Total = 2 cycles for 4 instructions → IPC = 2 (peak!). Ek scalar machine 4 cycles leti (IPC = 1). Speedup = 2×.

Worked Example 2 — ek dependency chain ILP barbad kar deti hai

I1: r1 = r2 + r3
I2: r4 = r1 + r5     (needs r1)
I3: r6 = r4 + r7     (needs r4)
I4: r8 = r6 + r9     (needs r6)

Har instruction pichli wali par depend karti hai.

4 cycles, IPC = 1 — doosre unit se koi fayda nahi. Yeh hamare formula mein $p=0$ hai. Steel-man lesson: width sirf tabhi help karta hai jab independent kaam exist kare.

Worked Example 3 — renaming se false dependency fix hoti hai

I1: r1 = r2 + r3
I2: r1 = r4 + r5     (WAW: r1 dobara likhta hai — lekin value independent!)

In-order naive view kehta hai "dono r1 likhte hain, serialize karo." Lekin values independent hain. Rename karo: I2 physical p7 likhta hai r1 ka physical reg reuse karne ki jagah. Ab woh saath issue hote hain, IPC = 2.

Why this step? Renaming prove karta hai ki conflict ek naming artifact tha, real data flow nahi.

Flashcards

Connections

• Pipelining — superscalar ek pipelined datapath par build hota hai.
• Instruction-Level Parallelism (ILP) — woh resource jise superscalar exploit karta hai.
• Out-of-Order Execution aur Register Renaming — high real IPC enable karte hain.
• Reorder Buffer (ROB) — in-order retirement guarantee karta hai.
• Branch Prediction — wide units ko control hazards ke baad bhi fed rakhta hai.
• Amdahl's Law — same math IPC_eff ko govern karta hai.
• VLIW — hardware superscalar ka compiler-scheduled alternative.
• Data Hazards (RAW WAR WAW) — jo issue width limit karte hain.

Concept Map