Tomasulo's algorithm padhne se pehle, tumhe ideas ki ek chhoti si toolkit chahiye. Neeche har symbol, structure, aur word hai jis par parent note depend karta hai — bilkul zero se, ek aisi order mein jahan har ek cheez pichli cheez par tikti hai. Yahan kuch bhi assume nahi kiya gaya; agar parent ne use kiya, toh hum define karte hain.
Isko imagine karo ek chhoti si machine ke roop mein jisme do input wires hain aur ek output wire.
Topic ko yeh kyun chahiye: Tomasulo ke har rule ko "sources padho, destination produce karo" ke terms mein likha gaya hai. Agar tum nahi dekh sakte ki kaun sa register source hai aur kaun sa destination, toh hazard ki saari baatein samajh nahi aayengi.
Register file ko numbered lockers ki ek row samjho. R2 = 2 ka matlab hai locker number 2 mein abhi number 2 hai.
Topic ko yeh kyun chahiye: instructions sirf registers se padhti aur registers mein likhti hain (is model mein). Ek register ka naam — locker par likha number — exactly wahi cheez hai jo Section 5 mein problem create karegi, isliye ab hum ise clearly define karte hain.
Topic ko yeh kyun chahiye: out-of-order execution hi pura point hai. Lekin yeh tabhi safe hai jab hum woh answer kabhi na todein jo program expect karta tha — isliye ab hum dependencies padhte hain.
Do instructions related ho sakti hain kuch tareekon se. Inhe clearly samajhna hi sab kuch hai. Dekho data-hazards.
Topic ko yeh kyun chahiye: parent ke poore "What Problem Does Tomasulo Solve?" section mein WAR/WAW hazards ko khatam karne aur RAW ko respect karne ki baat hai. Tumhe real dependency aur fake dependency mein fark karna aana chahiye.
Yeh sabse clever idea hai, isliye hum ise dheere-dheere build karte hain.
Topic ko yeh kyun chahiye: tags hi renaming hain. Jab R1.tag = Mult1 hai, register R1 ab ek number nahi hai — yeh ek note hai jo kehta hai "station Mult1 ka intezaar kar raha hun." Isi tarah se do R1s do alag cheezein ban jaati hain.
Pairs ko aise padhein: har source ke liye tumhare paas ya toh value V hai ya tag Q — dono nahi, aur kuch nahi bhi nahi.
Topic ko yeh kyun chahiye: poora algorithm Vj,Vk,Qj,Qk ke terms mein likha gaya hai. Agar woh chaar symbols blur hain, toh pseudocode padhna impossible hai. Unke naam bas yeh hain: V = Value, Q = "Queue tag jiska intezaar kar raha hun"; j = pehla source, k = doosra source.
Topic ko yeh kyun chahiye: ek reservation station ek FU se "attached" hoti hai. RS waiting instruction hold karta hai; FU kaam karta hai jab operands aa jaate hain.
Har arrow ka matlab hai "left wala idea samjhe bina right wala nahi samjhoge." Notice karo ki tag reservation stations aur CDB dono ko feed karta hai — yeh poore design ka glue hai.
Dono operands ready hain, toh instruction ab run kar sakti hai.
Common Data Bus par kya travel karta hai?
Ek pair ⟨tag,value⟩ — ek finished station ka naam aur uska result.
Result ko specific consumers ki jagah sabko broadcast kyun karo?
Kyunki issue ke time kisi ko nahi pata ki kitni baad wali instructions ko yeh chahiye hoga; ek baar broadcast karna zyada simple hai.
Jab upar ki har line easy lage, tab tum Tomasulo's algorithm ke liye ready ho — ya pehle isko Hinglish mein padho. Related deeper dives: reorder-buffer, scoreboarding, memory-disambiguation.