Question bank — VLIW architectures
5.3.13 · D5· Hardware › Advanced Microarchitecture › VLIW architectures
Shuru karne se pehle, in questions mein jo vocabulary use hoti hai uska ek-line refresher, taaki koi bhi term use hone se pehle anchored ho jaye:
Recall Woh paanch words jo har question mein reuse hote hain
Functional unit ::: ek hardware ka tukda jo ek tarah ka kaam karta hai (ek integer adder, ek load/store port, ek multiplier). Ek single cook ko ek station par picture karo. Slot ::: ek wide instruction ke andar ek fixed field jo ek functional unit ko batata hai ki is cycle mein kya karna hai. Ek meal-kit tray ke ek compartment ko picture karo. NOP ::: "no operation" — woh placeholder jo tum ek slot mein daalte ho jab compiler ko us unit ke liye us cycle mein koi useful kaam nahi mila. Ek khali tray compartment. Static scheduling ::: compiler decide karta hai, program ever run hone se pehle, ki kaunse operations kaunse cycle ke kaunse slot mein jaayenge. Runtime par kuch bhi re-decide nahi hota. Interlock ::: hardware jo ek instruction ko tab tak stall karta hai jab tak uske inputs ready na ho jaayein. VLIW jaanbujhkar inhe remove karta hai aur compiler par trust karta hai.
True or false — justify karo
Recall VLIW hardware runtime par instruction-level parallelism discover karta hai.
False ::: Compiler compile time par parallelism discover karta hai aur use instruction word mein freeze kar deta hai; VLIW hardware bas har slot ko uske unit tak plain combinational logic se route karta hai — chip par koi runtime dependency search exist nahi karta.
Recall Teen NOPs aur ek real op wala ek VLIW instruction memory mein full instruction-word width occupy karta hai.
True ::: Slots fixed-length fields hain, isliye unused slots NOP bit-patterns se fill hote hain jo phir bhi space lete hain — exactly yahi wajah hai ki low-parallelism code VLIW code density ko hurt karta hai.
Recall Kyunki VLIW interlocks remove karta hai, ek compiler bug jo RAW dependency ignore karta hai woh sirf slow chalega.
False ::: Koi interlock nahi hone ki wajah se hardware kabhi wait ke liye stall nahi karta, isliye ek missed RAW galat result deta hai (reader ko stale data milta hai), slow result nahi. Correctness ab compiler mein rehti hai.
Recall Agar ek VLIW machine mein 4 slots hain, to us par har program scalar RISC se 4× faster chalta hai.
False ::: Slots parallelism ki upper bound hain, guarantee nahi. Ek dependent chain (jaise Fibonacci loop) ek cycle mein ek slot fill karta hai aur ≈1× milta hai — VLIW existing parallelism ko exploit karta hai, woh use manufacture nahi kar sakta.
Recall Note ki 4-issue machine (ek memory port) par, tum ek single instruction word mein do loads issue kar sakte ho.
False ::: Exactly ek load/store functional unit hai, isliye ek cycle mein zyada se zyada ek memory op. Do loads ko do consecutive instruction words occupy karne padenge chahe kitne bhi khali ALU slots baajoo mein kyun na hon.
Recall WAR aur WAW dependencies ek strict ordering force karti hain jo compiler bhi remove nahi kar sakta.
False ::: WAR (write-after-read) aur WAW (write-after-write) register names ke reuse se caused false dependencies hain. Fresh registers par renaming inhe remove kar deta hai; sirf RAW (ek genuine data flow) ko preserve karna zaroori hai.
Recall Lock-step execution ka matlab hai ki saare functional units har cycle mein ek saath next instruction word par advance karte hain.
True ::: Ek wide word ke har slot usi cycle mein issue hote hain aur poora word saath retire hota hai — koi per-unit reorder buffer nahi hai jo kisi ek unit ko doosre se aage jaane de.
Recall Same issue width ki ek superscalar processor aur ek VLIW processor ko roughly same amount of scheduling hardware chahiye.
False ::: Superscalar hardware mein schedule karne ke liye wakeup/select, renaming aur reorder buffers par O(n²)-ish area kharach karta hai; VLIW woh kaam compiler par shift kar deta hai, isliye uska scheduling hardware comparison mein tiny hota hai.
Error dhundho
Recall "VLIW superscalar se faster hai kyunki yeh zyada instructions per cycle issue karta hai." — galti dhundho.
Galti ::: Dono ko same issue width par banaya ja sakta hai; VLIW ka advantage simpler, lower-power hardware hai, zyada slots nahi. Equal width aur equal parallelism dete hue woh same amount issue karte hain — win die area, power, aur clock mein hai, raw issue count mein nahi.
Recall "Kyunki compiler statically schedule karta hai, VLIW performance actual runtime data se bilkul independent hai." — galti dhundho.
Galti ::: Cache misses aur variable-latency memory runtime effects hain jo static schedule anticipate nahi kar sakta. Ek load jo (say) 2 cycles lene ki assumption par tha agar actually miss karta hai to poora lock-step word stall karega, isliye runtime data phir bhi matter karta hai.
Recall "Saare 4 slots exploit karne ke liye hum compiler ko ek word mein char independent instructions daalne ko bol dete hain." — galti dhundho.
Galti ::: Tum independence daal nahi sakte agar program mein us point par char independent ops hain hi nahi. Compiler ko ise dhundhna ya create karna hoga (loop unrolling, software pipelining), aur agar code ek dependent chain hai to woh honestly NOPs emit karega.
Recall Ek student note ki array-add loop likhta hai aur "cycles save karne" ke liye do loads plus ek store ek instruction mein pack karta hai. — galti dhundho.
Galti ::: Iske liye teen memory ports chahiye; machine mein ek hai. Compiler ko yeh reject karna hoga aur memory ops ko words ke across serialise karna hoga — single memory port throughput bottleneck hai.
Recall "Register renaming ek runtime hardware feature hai, isliye VLIW compilers yeh nahi karte." — galti dhundho.
Galti ::: VLIW mein koi renaming hardware hai hi nahi, isliye compiler khud scheduling ke dauran renaming karta hai WAR/WAW hazards break karne ke liye. Kaam disappear nahi hota; woh move ho jaata hai.
Recall "Fibonacci loop ki 25% slot utilisation prove karti hai ki VLIW machine broken hai." — galti dhundho.
Galti ::: Low utilisation program ki parallelism ki kami reflect karta hai, hardware fault nahi. Ek serial recurrence kisi bhi machine par one-op-at-a-time chalta; VLIW sirf khali slots ko NOPs ke roop mein visible bana deta hai.
Why questions
Recall VLIW variable-length ones ki jagah
fixed-length instruction words kyun use karta hai? Kyunki ::: Fixed positions decoder ko har slot ko uske functional unit tak simple combinational logic se route karne dete hain — koi length-decoding ya dynamic dispatch matrix nahi. Iska price woh NOPs hain jo unused slots pad karte hain.
Recall Dynamic scheduling ki hardware complexity issue width ke saath super-linearly (roughly O(n²)) kyun grow karti hai?
Kyunki ::: Wakeup/select aur dependency-checking logic ko har in-flight instruction ko har doosre se compare karna hota hai, isliye structures instructions ke pairs ke saath scale hote hain. Width double karne par logic do se zyada ho jaata hai — compiler par offload karne ki motivation yahi hai.
Recall VLIW mein compiler ko, hardware ko nahi, "heavy lifting" better kyun karne milti hai?
Kyunki ::: Compiler ke paas unlimited time aur pure program ki global visibility hoti hai, jabki hardware ko sirf ek local window use karke ek cycle ke andar decide karna hota hai. Global static analysis woh parallelism dhundh sakti hai jo hardware miss kar deta.
Recall
do bounds ka sum ya minimum kyun nahi, balki maximum kyun hai? Kyunki ::: Dono constraints simultaneously hold karni chahiye — schedule utna fast nahi ho sakta jitna resources allow karein aur utna fast nahi ho sakta jitna recurrences allow karein. Dono mein jo tighter (bada) ho woh govern karta hai, isliye tum max lete ho.
Recall Ek single memory port ek loop ki throughput ko ek memory op per cycle par kyun cap kar sakta hai chahe kitne bhi ALU slots add karo?
Kyunki ::: jab memory copy: agar loop ko kaafi memory ops chahiye, ceiling kam se kam utne cycles per iteration force karta hai. Extra ALU slots memory traffic carry nahi kar sakte, isliye woh bas NOPs baith jaate hain.
Edge cases
Recall Ek VLIW instruction kaisi dikhti hai jab compiler ko ek cycle ke liye
zero parallel work milta hai? Ek real op plus NOPs ::: Yeh code density ka worst case hai: tum ek single operation karne ke liye full instruction-word width pay karte ho — wide-instruction memory cost par sequential performance.
Recall Code-density formula
mein, boundary par kya hota hai? Efficiency collapse ho jaati hai ::: ka matlab hai ek word mein ek useful op, isliye pehla factor hai — tum ek useful op per slots' worth of bits transmit karte ho. VLIW ki density exactly tab worst hoti hai jab parallelism lowest ho.
Recall
ki best-case value kya hai, aur yeh kya represent karta hai? ::: Har slot mein ek real operation hai, jo full utilisation deta hai. Yeh woh ceiling hai jo compiler unrolling aur software pipelining se chase karta hai; real code usually aur ke beech kahin land karta hai.
Recall Ek dependency cycle ki latency 4 hai aur iteration distance 1 hai. RecMII kya kehta hai, aur agar distance 4 hoti to?
RecMII , phir ::: cycles per iteration ek tight self-recurrence ke liye; usi latency ko distance 4 par spread karne se milta hai, kyunki result sirf chaar iterations baad chahiye, overlap karne ki slack chodta hai.
Recall Degenerate case: ek loop body mein
koi bhi dependency cycles nahi — II ko kya bound karta hai? Sirf ResMII ::: Koi recurrences nahi hone par, RecMII effectively zero hai (constrain karne ke liye koi cycle nahi), isliye initiation interval purely resource copies se set hoti hai — loop hardware ports se limit hoti hai, data feedback se nahi.
Recall Kya hota hai poore lock-step word ko agar ek slot ki operation stall ho jaaye (e.g. ek unexpected cache miss)?
Poora word stall ho jaata hai ::: Kyunki saare slots saath issue aur retire hote hain, ek late unit doosron ko freeze kar deta hai — VLIW independent slots ko aage jaane nahi de sakta, jo koi reorder buffer na hone ka trade-off hai.