5.2.8 · D5 · HinglishProcessor Datapath & Pipelining
Question bank — Control hazards and pipeline flushes
5.2.8 · D5· Hardware › Processor Datapath & Pipelining › Control hazards aur pipeline flushes
Traps se pehle, ek shared vocabulary anchor hai taaki koi term bina samjhe use na ho. Neeche wali figure map hai — jawab dete waqt isko saamne rakhna:
Doosri figure dikhati hai ki "do instructions flush karna" ek timing chart mein exactly kaisa dikhta hai — jab bhi koi trap fetch, resolve, ya bubble mention kare, isse refer karo:
True or false — justify karo
Branch instruction khud flush ho jaata hai jab woh taken hota hai.
False. Branch sahi hai — use finish hona chahiye aur PC update karna chahiye. Hum sirf un wrong-path instructions ko flush karte hain jo iske baad fetch hue (PC+4, PC+8 par).
Ek flushed instruction memory (RAM) se erase ho jaata hai.
False. Flushing sirf ek pipeline register mein baithe copy ke control signals ko zero karta hai; memory mein bytes untouched rehte hain aur agli baar jab control wahan pahunche, normally execute honge.
Ek branch jo predict-not-taken machine par not taken hai, uski penalty zero hoti hai.
True. Speculatively fetch kiye gaye PC+4 instructions sahi the, isliye kuch flush karne ki zaroorat nahi — guess sahi nikla.
Branch prediction saare control-hazard penalties khatam kar deti hai.
False. Prediction sirf penalty ko reduce karti hai zyaadaatar sahi hoke; har misprediction abhi bhi wrong-path instructions ka pura flush trigger karta hai.
Branch ko ek stage pehle resolve karna (ID mein EX ki jagah) penalty hamesha halve kar deta hai.
Yahaan roughly true hai, lekin ise halving ki jagah subtraction ki tarah state karo. Penalty = (resolve stage) − (fetch stage); EX se ID par jaane se yeh 2 se 1 ho jaata hai — yeh 2 ko halve karta hai, lekin rule hai "ek stage pehle = ek kam flushed instruction".
2-bit saturating counter ek loop mein 1-bit counter se kam baar mispredicts karta hai.
True. 1-bit predictor single loop-exit miss par flip karta hai aur phir agli loop ki entry par galat hota hai (2 misses); 2-bit counter ko flip hone ke liye do consecutive misses chahiye, isliye woh "Taken" rehta hai aur sirf exit par miss karta hai (1 miss).
Control hazards aur data hazards ek hi underlying problem hain.
False. Data hazard ek operand ki value ke baare mein hai (dependency); control hazard agla instruction fetch karne ke baare mein hai. Contrast ke liye 5.2.05-Data-hazards-and-forwarding dekho.
Predict-taken predict-not-taken se strictly better hai kyunki zyaadaatar branches taken hote hain.
False. Predict-taken ko target address pehle compute karna padta hai (ID mein ek adder jo PC ko feed kare); woh hardware ke bina target fetch nahi kar sakte, isliye "zyaadaatar branches taken" akele kafi nahi.
Agar branch not taken ho, toh kisi bhi machine par koi instruction flush nahi karna padta.
Saamanya roop mein False. Predict-taken machine par ek not-taken branch ka matlab hai ki speculatively fetch kiye gaye target instructions galat hain aur flush karne padenge.
Bubbles pipeline ki clock frequency slow kar dete hain.
False. Bubbles per-stage timing nahi badlate; woh cycles waste karte hain (throughput), clock period nahi. Pipeline phir bhi usi rate par tick karta rehta hai.
Error dhundho
"Hum branch ko flush karte hain taaki wrong path kabhi run na ho." — Kya galat hai?
Hum branch ko flush nahi karte; hum wrong-path successors ko flush karte hain. Branch ko sahi PC set karne ke liye complete hona zaroori hai. Branch ko flush karna wahi instruction kho dena hoga jo compute karta hai kahan jaana hai.
"Predict-not-taken ke saath, penalty = 2 cycles × , isliye 50% taken branches wali machine hamesha exactly 1 cycle per branch khoti hai." — galti pakdo.
"Exactly 1" zyaada claim karta hai — yeh average hai (), per-branch value nahi. Har individual not-taken branch 0 cost karta hai aur har taken waala 2; woh 1 ek statistical mean hai.
"100-iteration loop mein ek 1-bit predictor ek baar (exit par) mispredicts karta hai." — galti dhundho.
Yeh do baar mispredicts karta hai: ek baar exit par (predicts taken, loop khatam) aur ek baar agli loop ki pehli iteration par (ab not-taken predict karta hai lekin loop dobara enter hota hai).
"Flush karne ke liye, bas instruction ko ID/EX register se delete karo." — 'delete' galat verb kyun hai?
Synchronized stages ko desynchronize kiye bina mid-flight mein ek slot remove nahi kar sakte. Tum ise ek bubble mein neutralize karte ho (RegWrite=0, MemWrite=0), taaki woh stage-by-stage advance karta rahe lekin kuch change na kare.
"BHT index = PC mod , isliye hum saare PC bits use karte hain including low 2." — kya off hai?
Instructions word-aligned hote hain, isliye low 2 bits hamesha 0 hote hain aur koi information nahi rakhte. Index use karta hai, woh constant bits drop karta hai taaki koi do useful addresses ek waste entry par collide na karein.
"95%-accurate predictor control hazards free bana deta hai." — correct karo.
Baaki 5% abhi bhi flush karte hain. Deep pipeline par chhoti miss rate bhi bahut cycles cost kar sakti hai, kyunki har miss kaafi instructions flush karta hai.
Why questions
Ek flushed instruction bubble kyun banana chahiye, simply vanish kyun nahi?
Kyunki pipeline stages lockstep mein march karte hain; ek missing slot downstream logic ko desynchronize kar dega. Bubble timing intact rakhta hai jabki architectural state kuch nahi karta.
Branch ko EX mein resolve karne par 2 flushes kyun hoti hain lekin ID mein sirf 1?
Penalty us galat-path instructions ki sankhya ke barabar hai jo resolution se pehle fetch ho gaye. IF aur EX ke beech do instructions enter hue; IF aur ID ke beech sirf ek ne kiya.
Taken branch penalty kyun cost karta hai jabki not-taken (predict-not-taken ke under) kuch nahi cost karta?
Predict-not-taken speculatively PC+4 fetch karta hai. Agar branch not taken hai toh woh fetches sahi the — koi flush nahi; agar taken hai toh galat the — flush karo.
Processors branch resolve hone tak stall karne ki jagah predict kyun karte hain?
Stalling har branch par penalty cycles unconditionally waste karta hai; predicting unhe sirf mispredictions par waste karta hai, isliye ek accha predictor almost hamesha sasta hota hai. 5.2.09-Branch-prediction-techniques dekho.
2-bit counter ko prediction change karne ke liye do consecutive misses kyun chahiye?
Iske chaar states hain hysteresis ke saath (Strong/Weak Taken, Weak/Strong Not-Taken); ek miss sirf Strong→Weak nudge karta hai bina taken/not-taken boundary cross kiye, isliye ek rare anomaly (jaise loop exit) dominant trend corrupt nahi karta.
Branch ko data hazard ki jagah control hazard kyun kaha jaata hai?
Yeh control flow ko khatre mein daalta hai — agla instruction kaun sa hai ka choice — na ki kisi operand ki value ki correctness ko.
Speculatively executed wrong-path instructions safely discard kyun kiye ja sakte hain?
Kyunki bubbles ke roop mein unhone kabhi koi register ya memory nahi likhi; jo kuch unhone touch kiya woh architectural state nahi bana, isliye unhe remove karna machine ko exactly waise chhodta hai jaise woh kabhi run hi na hue hon. Yeh 5.2.11-Speculative-execution ki foundation hai.
Edge cases
Ek branch jahan condition hamesha true hai (unconditional jump). Kya predict-not-taken kabhi help karta hai?
Nahi — yeh har baar mispredicts karega (hamesha taken), har baar full penalty pay karke. Aisi branches exactly isliye hain predict-taken ya BTB target-cache exist karta hai.
Pehli baar jab ek branch BHT dwara dekha jaata hai: kya prediction use hoti hai?
Jo bhi entry ki initial/aliased state ho — predictor ke paas koi history nahi hai, isliye "prediction" essentially reset default hai (often Strongly/Weakly Taken set taaki loops favor ho).
Do alag branches ek hi BHT index par hash karte hain (aliasing). Kya galat ho sakta hai?
Woh ek counter share karte hain, isliye ek branch ka behaviour doosre ki prediction corrupt karta hai, misprediction rate badhata hai. Yeh "destructive aliasing" isliye index bits aur tagging important hain.
Back-to-back branches ka pair, doosra pehle ke wrong-path slot mein hai. Flush par kya hota hai?
Doosra branch bhi bubble ke roop mein flush ho jaata hai — woh kabhi resolve nahi karta aur kabhi predict nahi karta, kyunki use pipeline mein bilkul hona nahi chahiye tha.
Ek branch jo predict-taken machine par not taken resolve karta hai, lekin target adder busy tha. Koi subtlety?
Penalty galat taur par fetch kiye gaye target instructions ka flush hai; "not taken" path (PC+4) ko ab refetch karna padega, isliye yahaan 1-cycle penalty target fetches discard karne se aati hai, condition delay se nahi.
Zero-iteration loop (entry par condition false): Strongly-Taken initialize counter se kitne mispredictions?
Ek — yeh taken predict karta hai lekin loop immediately skip ho jaata hai, isliye single entry mispredicts karta hai aur koi "99 correct" cushion exist nahi karta.
Recall Lock karne ke liye ek-line summary
Followers ko flush karo, branch ko nahi; bubbles cycles waste karte hain memory nahi; prediction penalty ko shrink karta hai — kabhi remove nahi karta.
Justify karo kyun penalty formula is par depend nahi karta ki branch forward hai ya backward.
Penalty pipeline stages ko count karta hai fetch aur resolve ke beech, jo hardware structure se fixed hai; direction sirf affect karta hai ki static predictor kitni baar sahi hota hai, per-miss cost par nahi.