Question bank — ISA (Instruction Set Architecture) — RISC vs CISC

ISA — the visible contract (instructions, registers, memory model) ::: the abstract interface software sees; independent of how the chip is built. Microarchitecture — the hidden implementation ::: the actual circuit design (pipeline depth, caches, execution units) behind a given ISA. Load/store rule — the RISC signature ::: arithmetic instructions touch only registers; memory is reached solely through explicit LOAD and STORE.

"RISC always beats CISC on runtime." ::: False — runtime is $IC\times CPI\times T_{cycle}$, so a workload where RISC's larger instruction count dominates can erase its CPI edge; the winner is workload- and technology-dependent, not fixed. "RISC means the ISA has fewer instructions." ::: False — "reduced" refers to the complexity and regularity of each instruction, not the count; many RISC ISAs have plenty of instructions, they're just simple and uniform. "A CISC chip cannot use a pipeline." ::: False — it can, but variable-length instructions and multi-step operations make pipelining harder; modern x86 solves this by translating to uniform micro-ops first, then pipelining those. "Two CPUs with the same ISA must have the same performance." ::: False — ISA is the menu, microarchitecture is the kitchen; Intel and AMD share x86-64 yet differ wildly in speed because they implement it differently. "Fixed-length instructions waste memory compared to variable-length." ::: True in general — a simple RISC op that only needs 12 bits still occupies the full 32-bit slot, so RISC code is typically less dense than CISC; that density cost was a big deal in the memory-scarce 1970s. "The load/store rule means RISC programs read memory less often." ::: False — the same data must still come from memory; the rule just forces those accesses into separate explicit LOAD/STORE instructions instead of hiding them inside arithmetic. "Microcode is a CISC-only idea." ::: Mostly historical — microcode (breaking one instruction into internal steps via a tiny control program) is classically CISC, but modern CISC uses micro-op decoding that plays the same role, while pure RISC leans on hardwired control instead. "A large register file automatically makes a design RISC." ::: False — many registers are a consequence of load/store (you need places to stage data), not the definition; x86-64 added registers yet stayed CISC in its external form.

"This ADD is RISC because it only takes one cycle: ADD r1, [mem]." ::: The error is the memory operand — a genuine load/store ADD may not touch memory at all; ADD r1, [mem] is a CISC-style memory-operand instruction regardless of its cycle count. "RISC-V is faster than x86 because RISC is a faster microarchitecture." ::: RISC-V is an ISA, not a microarchitecture; speed comes from the specific chip implementing it, so comparing "RISC vs x86" as if they were kitchens is a category error. "CISC keeps IC low, so by the Iron Law CISC always minimizes T." ::: The Iron Law has three factors; lowering $IC$ typically raises $CPI$ and can lengthen $T_{cycle}$, so the product isn't guaranteed smaller — you can't optimize one factor and ignore the other two. "Because ARM added lots of instructions, ARM is now CISC." ::: Instruction count isn't the criterion; ARM stays load/store with fixed-form (or clean fixed/compressed) encodings, so it keeps the RISC philosophy even as its instruction menu grows. "The compiler is irrelevant to whether RISC wins." ::: Wrong — RISC deliberately pushes complexity into the compiler; a weak compiler that can't schedule and allocate registers well throws away RISC's whole advantage. "A modern Intel CPU is pure CISC top to bottom." ::: It's CISC on the outside (x86-64 contract) but decodes into RISC-like micro-ops executed in a RISC-style pipeline inside — the strict outside/inside distinction is the point. "Lowering $T_{cycle}$ (faster clock) always lowers program time." ::: Not necessarily — pushing the clock faster can force more pipeline stages, raising stalls and effective $CPI$, so the product $CPI\times T_{cycle}$ may not improve; see CPI and the Iron Law of Performance.

Why does RISC insist arithmetic operate only on registers? ::: Uniform register-only operations all take the same shape and timing, which is exactly what a pipeline needs to keep a steady rhythm without special-casing memory latency mid-instruction. Why did CISC's fat instructions make sense in the 1970s? ::: Memory was tiny and expensive and people hand-wrote assembly, so dense code (few bytes) and instructions that mirror high-level operations were worth the complicated hardware. Why did RISC become attractive once compilers improved? ::: Studies showed compilers barely used CISC's fancy instructions and mostly emitted a small simple subset, so simplifying the hardware to match what software actually generated was a net win. Why can splitting one CISC instruction into several RISC instructions still be faster? ::: Each simple instruction can run near one cycle in a pipeline and the clock can be faster, so even with a higher $IC$ the product $IC\times CPI\times T_{cycle}$ can shrink. Why is decode complexity central to the RISC/CISC split? ::: Fixed-length regular encodings can be decoded by fast hardwired logic, whereas variable-length instructions need complex decoding (and often microcode), which raises $CPI$ and pressures the clock period. Why do we say "one ISA, many microarchitectures"? ::: The ISA fixes only the software-visible contract, leaving implementers free to choose pipeline depth, cache design, and execution width — so many differently-performing chips honor the same contract, per Microarchitecture vs ISA. Why does RISC typically need more registers than early CISC? ::: With load/store, every operand must first be staged in a register, so you need enough registers to hold intermediate values without constantly spilling to memory; see Registers and the Register File. Why doesn't a memory-heavy workload favor RISC as strongly? ::: When runtime is dominated by memory latency and misses, instruction encoding matters less, so RISC's clean pipeline advantage is partly hidden behind stalls both designs share.

What if a "RISC" ISA adds a variable-length compressed encoding (like RISC-V's C extension)? ::: It's still RISC in philosophy — load/store and register-to-register semantics are unchanged; the compact encoding is a code-density optimization, not a switch to CISC's memory-operand model. What if $CPI$ is exactly equal for a RISC and CISC design? ::: Then the Iron Law reduces to $IC\times T_{cycle}$, and CISC's lower instruction count can win — showing RISC's edge lives specifically in the CPI (and clock) factor. What happens to the Iron Law if a program is one single instruction ($IC=1$)? ::: Time collapses to $CPI\times T_{cycle}$ for that one instruction; a huge multi-cycle CISC instruction can still be slow, so a tiny $IC$ alone guarantees nothing. What if the clock is pushed so high that pipeline stalls dominate? ::: Effective $CPI$ climbs because stall cycles count as extra cycles per instruction, so a "faster" $T_{cycle}$ can be cancelled by a worse $CPI$ — the two factors are not independent. What about a CISC instruction that happens to run in one cycle? ::: It exists (simple CISC ops can be single-cycle), which is why cycle count alone can't classify an ISA — the defining trait is whether arithmetic may address memory, not per-instruction timing. What if a compiler emits only the simple subset of a CISC ISA? ::: Then it's effectively using CISC like a RISC, which is exactly the 1980s observation that motivated RISC — the fancy instructions were being left unused. Degenerate case: an ISA with zero addressing modes beyond register-direct — is that maximal RISC? ::: It's extremely RISC-like, but real load/store ISAs still need at least a base+offset addressing mode to reach memory at all, so "zero modes" would make LOAD/STORE unusable — some minimal addressing is unavoidable. What if two chips share an ISA but one has microcode and the other is fully hardwired? ::: Perfectly legal — control-unit style is a microarchitecture choice hidden from software, so both still honor the same contract and only their $CPI$/clock characteristics differ.