Question bank — Instruction formats and encoding

False. Har instruction same width ka hota hai, lekin ek format fields ko unused chhod sakta hai ya unke bits ko repurpose kar sakta hai (jaise I-type, rs2+funct7 ko 12-bit immediate mein badal deta hai). Fixed width ≠ fixed field usage.

False. RISC-V mein opcode lowest 7 bits mein rehta hai (likhne par sabse daayein), aur decoder wahan padhta hai. "Fixed position" ka matlab fixed hai, zaruri nahi ki leftmost ho — dekho Instruction Decode Stage.

Lower bound ke roop mein True: $\lceil {\log }_{2}32\rceil =5$. Lekin real ISAs aksar ek wider primary opcode plus funct sub-fields use karte hain taaki word redesign kiye bina baad mein operations add kar sakein.

False. Yeh isliye chahiye taaki ek single field negative numbers rakh sake (jaise addi x1, x2, -8); top bit sign bit hota hai. Dekho Two's Complement and Sign Extension.

False — yeh ek trade-off hai. Variable (x86) denser code aur better instruction-cache hits deta hai; fixed (RISC-V, MIPS, ARM) fast, parallel decode deta hai. Koi bhi dominant nahi; dekho RISC vs CISC.

True. Formats mein rs1 (aur jahan ho wahan rs2) ko fixed bit positions par rakhne se matlab hai ki Registers and the Register File read ports usi tarah wire hote hain; sirf immediate-assembly logic badalta hai.

Partly false. "Spare" patterns waste nahi hain — yeh future instructions ke liye reserved room hain, aur 7 bits $7+5+5+5+3+7=32$ ko tidy rakhta hai. Spare opcode space ek feature hai, leakage nahi.

False. U-type (lui, auipc) apne 20 bits ko seedha ek 32-bit value ke upper part mein rakhta hai (bits 31:12); J-type (jal) apne 20 bits ko ek signed jump offset mein reorder aur scale karta hai. Same width, bahut alag plumbing.

False. B-type immediate scaled, sign-extended store hota hai, aur uske bits reordered/scattered hote hain. Raw field ko reassemble karna padta hai tab jaake woh real offset banta hai — neeche B-type walkthrough dekho.

rs1/rs2/rd ko wide karna usi fixed word se bits chheenta hai. 32 se 64 registers (5→6 bits) jaane se teen fields mein 3 extra bits lagte hain, immediate ya opcode room shrink ho jaata hai. Budget fixed hai.

Split isliye hai taaki rs1 aur rs2 apni usual positions par rahe. Registers ko fixed rakhna read logic ko simplify karta hai; immediate jo bhi leftover holes hain woh leta hai. Yeh ek deliberate hardware win hai, laziness nahi.

Decoder pehle opcode (low 7 bits) padhta hai class jaanne ke liye, phir funct3/funct7 us class ke andar add vs sub disambiguate karte hain. Opcode lead karta hai; funct refine karta hai.

Yeh unsigned range hai. Signed two's-complement 12 bits $-2048$ se $+2047$ tak cover karta hai — same 4096 patterns, lekin aadhe negative hain kyunki top bit sign bit hai.

Zero-padding $-8$ ko ek bada positive number bana deta. Sign-extension sign bit ko naye high bits mein copy karta hai, value preserve karta hai: $-8$ rehta hai $-8$. Dekho Two's Complement and Sign Extension.

Variable-length encoding mein tum instruction $n+1$ ko locate nahi kar sakte jab tak tum instruction $n$ ki length nahi jaante — ek serial dependency. Woh length-finding step woh bottleneck hai jo fixed-length avoid karta hai.

Yeh sub-selectors hain jo primary opcode budget grow kiye bina ek primary opcode class ke andar operations expand karte hain. Yeh primary opcode budget ek baar spend karke operations multiply karne dete hain.

lui woh 20 bits bits 31:12 mein rakhta hai aur low 12 bits zero-fill karta hai, isliye value immediate 12 left shift hoti hai — ek badi number, jo ek following addi ke saath mil kar full 32-bit constants banane ke liye use hoti hai.

Taaki decoder hamesha yeh kis type ka instruction hai dhundh sake kuch bhi jaanne se pehle, jisse woh decide kar sake ki baaki bits ko kaise interpret karna hai. Fixed opcode position = decode immediately aur parallel mein shuru ho sakta hai.

ALU full 32-bit values par kaam karta hai. Ek 12-bit field ko apna numeric meaning preserve karte hue wide karna padta hai, isliye sign bit replicate hota hai — warna negatives silently bade positives ban jaate.

32-bit word ek fixed budget hai. Opcode par spend kiya har bit immediate/register fields ke liye unavailable ho jaata hai, isliye bada opcode directly encode kiye ja sakne wale immediate ka size shrink karta hai.

Common tiny operations 4 ki jagah 1 byte mein fit ho jaati hain, isliye programs kam memory occupy karti hain. Denser code matlab same cache mein zyada instructions fit hoti hain, hit rate badhti hai aur memory bandwidth ka bojh kam hota hai.

Unhe alag-alag cheezein chahiye — teen registers vs. do registers plus ek number vs. ek register plus ek bada jump distance. Ek rigid layout ya toh bits waste karta ya immediate space mein short pad jaata, isliye multiple formats same 32 bits ko alag-alag tarah reuse karte hain.

Yeh bade values banane ke liye exist karte hain: U-type ek 32-bit constant/address ke high 20 bits set karta hai, aur J-type door ke jump targets tak pahunchta hai. Dono ko rs2 nahi chahiye, isliye woh freed bits ek wide immediate ko de diye jaate hain.

Kyunki valid branch targets hamesha ek aligned instruction boundary par land karte hain, lowest offset bit(s) jaane-maane hote hain ki 0 honge aur unhe store karne ki zarurat nahi — isliye same stored bits se aur door pahuncha ja sakta hai. Caveat: base RV32I mein instructions 4-byte aligned hote hain, isliye true useful step aur bhi coarse hai; spec mein "2 bytes ke units" scaling isliye hai kyunki optional compressed (C) extension 2-byte-aligned instructions allow karta hai. Neeche wala walkthrough scattered bits kaise reassemble hote hain yeh unpack karta hai.

$\lceil {\log }_{2}1\rceil =0$ bits — ek cheez ko khud se distinguish karne ke liye koi opcode nahi chahiye. Practice mein tum future growth ke liye bits reserve karte, lekin mathematically zero kaafi hai.

$\lceil {\log }_{2}64\rceil =6$ bits, koi spare pattern nahi — $2^6=64$ codes mein se har ek assign hai. Ek bhi aur operation add karna 7th bit force karega.

Dono cases mein zero — sign bit 0 hai, isliye signed aur unsigned 0 par agree karte hain. Interpretations tabhi alag hoti hain jab top bit 1 ho.

Immediate do leftover regions mein split ho jaata hai (S-type), rs1/rs2 fixed rakhte hue. Decoder use karne se pehle scattered pieces ko ek 12-bit value mein reassemble karta hai.

Nahi. Maximum $+2047$ ($2^{11}-1$) hai; $+2048$ positive end overflow karta hai. Tumhe ek alag sequence chahiye (jaise lui + addi) — ek real limit jise assemblers tumhare liye handle karte hain.

Nahi. Sabse negative 12-bit two's-complement value $-2^{11}=-2048$ hai; $-2049$ ek step neeche hai aur negative end overflow karta hai. Signed window asymmetric hai: yeh positive ($+2047$) se ek zyada negative ($-2048$) tak pahunchta hai.

20 bits bits 31:12 fill karte hain, isliye register woh field 12 left shift hoke laata hai: $2^{12}=4096$ ke multiples, $0$ se $4294963200$ tak. Yeh upper part set karta hai; low 12 bits zero rehte hain jab tak ek baad ka addi unhe fill na kare.

Nahi — yeh ISA par depend karta hai. RISC-V mein opcode 0000000 unassigned hai, isliye ek all-zeros word illegal trap karta hai (zeroed memory mein jump karne ke against ek useful safety net). Lekin doosre ISAs deliberately all-zeros pattern ko NOP (kuch mat karo) define karte hain. Rule ISA-specific hai, universal nahi.