Is page pe assume kiya gaya hai ki aapne parent note Control hazards and pipeline flushes mein stage, PC, bubble, branch, EX, saturating counter jaisi words dekhi hain. Neeche hum un sabhi symbols ko bilkul zero se banate hain, ek aisi order mein jahan har idea sirf usse pehle waale ideas pe tikta hai.
Ek lambi locker wall imagine karo. Har locker pe ek number likha hai, aur andar ek command hai. Parent note mein aapne 100:, 104:, 108: jaise labels dekhe. Woh numbers hi addresses hain.
Numbers 4 se kyun jump karte hain. Har instruction 4 bytes wide hota hai (ek common RISC choice), aur memory bytes mein count hoti hai. Toh address 100 ke baad wala locker 104 hai, 101 nahi. Jab bhi parent PC+4 likhta hai, iska matlab hai "bilkul agla instruction, iske thoda neeche wala".
Normal step: PC←PC+4 (ek locker neeche slide karo).
Branch taken: PC←branch target (finger ko kahin aur jump karo).
Arrow ← ka matlab hai "se replace ho jata hai". Hume PC isliye chahiye kyunki machine ko agla command grab karne se pehle ek address ready hona chahiye — aur woh "pehle" hi har control hazard ki jad hai.
Todna kyun? Ek instruction ek lambe step ki jagah 5 chhote steps leta hai. Jab instruction A EX mein hai, instruction B ID mein ho sakta hai, aur instruction C IF mein — ek saath teen instructions in flight. Yahi overlap hai jiski wajah se hum pehle hi fetch karna shuru kar dete hain, branch ka jawab jaane bina.
EX villain kyun hai. Is classic layout mein branch ka haan/nahi answer EX tak — teesre stage tak — nahi pata. Tab tak do chhote instructions IF aur ID mein ghus chuke hote hain.
Recall Stages overlap karna hi control hazards
kyun cause karta hai?
Kyunki agle instruction ke liye IF do ticks pehle hota hai EX se pehle ki branch resolve ho — toh hume guess pe fetch karna padta hai. ::: Overlap force karta hai ki hum branch outcome pata chalne se pehle hi fetch karein.
Isliye parent ek table draw karta hai cycles as columns aur stages as rows (IF/ID/EX/MEM/WB) ke saath. Padhne ka tarika: har instruction diagonally down-right chalti hai, ek tick mein ek stage.
Amber diagonal trace karo: BEQ cycle 1 mein IF mein hai, cycle 2 mein ID mein, cycle 3 mein EX mein — yahi woh cycle hai jab finally answer pata chalta hai. Iske peeche ADD aur SUB ghus chuke hain. Agar branch taken hai, toh woh dono galat path pe hain.
Saare registers + saari memory ka collection architectural state hai — program ka officially visible result. Flushing ka golden rule: ek wrong-path instruction ko architectural state touch karne se rokna zaroori hai.
Assembly line pe ek clear gap imagine karo jahan koi real product hona chahiye tha. Line in step rehti hai (kabhi desynchronised nahi hoti) par us slot pe kuch nahi banta.
Subtract kyun karte hain? IF ke baad branch jo bhi stage travel karta hai, woh ek extra younger instruction hai jo uske peeche aa gayi. Ek stage pehle (ID mein) resolve karo aur sirf 2−1=1 flush karoge.
Hum two-bit value ko aise padhte hain: 11 Strongly-Taken, 10 Weakly-Taken, 01 Weakly-Not-Taken, 00 Strongly-Not-Taken. "Saturating" ka matlab hai yeh 00 se neeche ya 11 se upar count nahi kar sakta — endpoints pe stick karta hai. Yeh ek idea Branch prediction techniques mein aur gehrayi se samjhaya gaya hai.
Yeh foundation seedha pipelining fundamentals mein feed karta hai, data hazards ke saath rehta hai, aur speculative execution ki taraf point karta hai. Ek Hinglish version the Hinglish note pe milega.