5.1.1 · D5 · HinglishInstruction Set Architecture (ISA)
Question bank — CISC vs RISC philosophies
5.1.1 · D5· Hardware › Instruction Set Architecture (ISA) › CISC vs RISC philosophies
Shuru karne se pehle, har question jis vocabulary pe tika hai uska ek-line refresher, taaki koi bhi term use hone se pehle samjha ja sake:
- = ek program mein execute hone wali instructions ki sankhya.
- CPI = har instruction average mein kitne clock cycles leta hai.
- = seconds per clock cycle (chhota = fast clock).
- Load/store architecture = sirf
LOAD/STOREmemory ko touch karte hain; arithmetic register-to-register chalti hai. - Microcode = ek internal recipe jo ek complex instruction ko kai chhoti internal steps (micro-ops) mein tod deti hai.
Har trap ke peeche ek picture



Sach ya jhooth — justify karo
Har item: true/false decide karo aur kyun bolo — "kyun" hi asli answer hai.
RISC programs mein hamesha equivalent CISC program se kam instructions hoti hain.
False. RISC mein aamtaur par zyada instructions hoti hain ( bada) kyunki ek CISC line aksar kai loads/adds/stores mein expand hoti hai; "Reduced" instruction simplicity ki baat karta hai, program length ki nahi (figure s01 mein left bar dekho).
Ek single CISC instruction hamesha us RISC sequence se kam cycles mein khatam hoti hai jise woh replace karti hai.
False. Ek rich CISC instruction ka high CPI (kai internal micro-ops) ho sakta hai, isliye instruction count kam hone ke bawajood total cycle count automatically kam nahi hota.
RISC multiply, divide, ya vector instructions ko bilkul forbid karta hai.
False. RISC-V aur ARM mein multiply/vector/crypto extensions hain; defining rules hain load/store separation + fixed-length encoding, useful operations ko ban karna nahi.
Load/store architecture mein, ADD R1, R2, [MEM] ek legal instruction hai.
False. Arithmetic operands sab registers hone chahiye; memory value ko pehle
LOAD se andar laana padega, phir add karo (figure s02 ka RISC column dekho).Fixed-length encoding ka matlab hai ki har RISC instruction utna hi kaam karta hai.
False. Fixed length in bytes sirf instructions ko pipeline mein fetch aur decode karna aasaan karta hai; ek shift aur ek multiply dono same 32 bits wide hote hain lekin bahut alag kaam karte hain.
Modern x86 processors pure CISC machines hain.
False. Woh bahar se CISC hain lekin har instruction ko RISC-like micro-ops mein decode karte hain jo ek internally RISC-style core pe chalte hain — ek hybrid, exactly jaisa figure s03 dikhata hai, Microcode and Micro-operations layer ke mutabiq.
ko kam karna hamesha ek program ko fast karne ka sabse acha tarika hai.
False. CPU time ; ko chhota karna tabhi help karta hai jab CPI aur compensate karne ke liye na badhe — yahi exactly CISC failure mode hai (figure s01).
Har RISC ISA mein exactly 32 general-purpose registers hote hain.
False. Yeh ek common design goal hai (MIPS, RISC-V, ARMv8) lekin classic 32-bit ARM mein sirf 16 integer registers hain aur woh phir bhi squarely RISC hai.
Microcode sirf CISC ka concept hai aur RISC cores mein kabhi koi nahi hota.
False. Classic RISC ne apni simple instructions ke liye hardwired control use kiya, lekin jaisa figure s03 ki timeline dikhati hai, modern RISC cores abhi bhi rare complex instructions ke liye microcode/μops pe fall back karte hain (aur x86 back-ends har jagah μops chalate hain). Precise claim yeh hai: microcode par bhari reliance CISC ko characterize karti hai, yeh nahi ki RISC mein bilkul nahi hoti.
Pipelining sirf RISC pe possible hai.
False. CISC bhi pipelined hai (saare modern x86 hain), lekin fixed-length, load/store RISC instructions zyada aasani aur predictably pipeline karti hain, jo RISC ka original advantage tha — figure s02 ke dono columns compare karo. Dekho Pipelining.
Error dhundho
Har statement mein flawed reasoning dhundho.
"RISC faster hai kyunki isne har program mein instructions ki sankhya kam kar di."
Error hai "instructions ki sankhya kam kar di" — RISC programs mein zyada instructions hoti hain. Speed aati hai low CPI + chhote + easy pipelining se, CPU Performance Equation ke mutabiq.
"Hamen CISC choose karna chahiye kyunki kam instructions ka matlab compiler ke liye kam kaam hai."
Error hai compiler effort ko goal samajhna. RISC jaanbujhkar complexity compiler mein daal deta hai (Compiler Optimization); mushkil compiler kaam woh price hai jo simpler, faster hardware paane ke liye di jaati hai.
"CISC ki variable-length instructions memory bachati hain, isliye CISC real programs pe hamesha RISC se behtar hota hai."
Error hai "hamesha." Code density ek axis hai; yeh CPI aur ko ignore karta hai. Chhota code jo slow clock pe high CPI pe chale total time mein phir bhi haar sakta hai (figure s01 mein area yaad karo).
"Kyunki x86 micro-ops mein decode hota hai, CISC/RISC distinction aaj meaningless hai."
Error hai "meaningless." Distinction ISA design philosophy level pe rehti hai (encoding, addressing modes, programmer-visible model) chahe silicon back-ends converge bhi karein.
"Load/store architecture slower hai kyunki ise extra LOAD aur STORE instructions chahiye."
Error hai "zyada instructions" ko "slower" ke barabar maanna. Woh extra instructions simple, single-cycle-ish hain, aur pipeline well karti hain, isliye total time phir bhi gir sakta hai — yahi RISC ki poori bet hai.
"Zyada addressing modes add karna hamesha ek ISA ko behtar banata hai kyunki programmers ko flexibility milti hai."
Error hai cost ko ignore karna: rich Addressing Modes decoding aur control ko complicate karte hain, CPI aur badhate hain — RISC critique yeh hai ki compilers ne unhe zyaadatar use hi nahi kiya.
Kyun wale questions
Chhote "kyun" reasoning — mechanism answer karo, sirf label nahi.
Fixed-length encoding pipelining ko kyun aasaan banata hai?
Fetch stage exactly jaanti hai agla instruction kahan shuru hota hai bina current one ko decode kiye, isliye instructions ek steady rate pe pipeline mein stream hoti hain (figure s02 mein even tiling). Dekho Instruction Encoding.
RISC faster kyun ho sakta hai jabki hai?
Kyunki CPI 1 ki taraf girta hai aur chhota hota hai (simple hardwired control), aur woh do reductions milke mein bade ko outweigh kar deti hain.
Arithmetic mein memory operands allow karna pipelining ko kyun hurt karta hai?
Ek instruction ab ek memory access aur ek computation bundle kar leti hai, isliye use multiple cycles chahiye aur woh stall karti hai, woh clean one-stage-per-cycle flow tod ke jo pipelines rely karti hain.
CISC philosophy 1970s mein kyun sense banata tha lekin 1980s tak kam?
1970s mein memory scarce/expensive tha aur code haath se likha jaata tha, isliye dense powerful instructions faydemand the; 1980s tak saste memory + smart compilers ne dono pressures hata diye.
CISC microcode pe kyun depend karta hai jabki RISC hardwired control pe?
Complex multi-step instructions ko sequence karne ke liye ek internal recipe (microcode) chahiye; RISC instructions itni simple hain ki direct combinational logic se control ki ja sakti hain, jo faster hai.
Zyada registers RISC style ko kyun support karte hain?
Registers operands ko memory se bahar rakhte hain, isliye load/store model lamba arithmetic sequences memory ke bina repeated slow trips ke kar sakta hai — registers ka point, unki exact count nahi. Related: x86 vs ARM.
"Har instruction ko zyada kaam karwao" free win kyun nahi hai?
Instruction ke per zyada kaam karna CPI badhata hai aur critical path lambi karti hai (bada ), isliye chhote se bachayi gayi time cancel ya reverse ho sakti hai.
Edge cases
Boundary aur degenerate scenarios jo yeh topic invite karta hai.
Agar compiler bahut poor ho, kya CISC design kabhi RISC ko beat kar sakta hai?
Haan — RISC complexity compiler pe daal deta hai, isliye ek weak compiler jo instructions badly schedule kare RISC ke low-CPI potential ko waste kar sakta hai, gap ko narrow ya erase kar ke.
Kya hoga RISC advantage ka agar CPI ko 1 ke paas nahi laaya ja sakta (jaise bahut saare cache misses)?
Bet kamzor pad jaati hai: agar stalls effective CPI inflate kar dein, RISC ka bada ab offset nahi hota, isliye real memory behaviour, sirf ISA nahi, winner decide karta hai.
Kya fixed-length instructions wala lekin arithmetic mein memory operands wala ISA RISC hai ya CISC?
Yeh key axis pe CISC ki taraf jhukta ek hybrid hai — load/store separation fixed length se zyada defining RISC trait hai, isliye memory arithmetic allow karna RISC model ko tod deta hai.
Sochte hain ek "RISC" chip jo internally ek rare instruction ke liye microcode use karta hai — kya woh phir bhi RISC hai?
Haan; philosophy poore ISA ke basis pe judge hoti hai (simple, load/store, fixed-length), ek exception pe nahi. Jaisa figure s03 dikhata hai, modern RISC cores bhi rare complex ops ke liye ek microcode path rakhte hain bina RISC band hue.
Jaise jaise CISC har instruction ko micro-ops mein decompose karta rehta hai, limiting case kya hai?
Woh andar se RISC ban jaata hai: visible ISA CISC rehta hai lekin execution RISC-jaisi hoti hai, jo exactly aaj ka x86 hai — do philosophies limit mein milti hain.
Out-of-order aur superscalar cores CISC-vs-RISC trade-off ko aur kaise blur karte hain?
Ek superscalar core kai μops per cycle issue karta hai aur ek out-of-order engine unhe stalls ke around reorder karta hai, isliye effective CPI dono CISC aur RISC front-ends pe 1 se neeche ja sakta hai — raw ISA kam maayane rakhta hai kyunki back-end (jo either way RISC-like hai) heavy lifting kar raha hai.
Kya out-of-order execution ek "bad" high-CPI CISC instruction ko rescue karta hai?
Kuch had tak — reordering kuch latency hide karta hai independent μops ko stall ke dauran chalake, lekin genuinely serial multi-μop instruction phir bhi resources occupy karti hai, isliye yeh throughput improve karta hai bina underlying cost ko mitaaye.
Agar do designs ka CPU time identical ho, kya CISC-vs-RISC choice phir bhi mayne rakhti hai?
Haan — yeh power, decoder area, code density, aur future compilers aur pipelines ke saath design kaise scale karta hai ko affect karta hai, isliye aaj equal time ka matlab equal engineering trade-offs nahi hai.
Recall Traps ka ek-line summary
Almost har misconception yeh bhoolne par collapse hoti hai ki time ek product hai (figure s01) — tum kisi bhi single factor se akele philosophy judge nahi kar sakte.