CISC vs RISC philosophies: Question bank — Hardware deep dive

Before we start, a one-line refresher of the vocabulary every question leans on, so no term is used before it is meant:

$N$ = number of instructions a program executes.
CPI = average clock cycles each instruction takes.
$T_{c}$ = seconds per clock cycle (small = fast clock).
Load/store architecture = only LOAD/STORE touch memory; arithmetic runs register-to-register.
Microcode = an internal recipe that turns one complex instruction into several tiny internal steps (micro-ops).

The one picture behind every trap

True or false — justify

Every item: decide true/false and say why — the "why" is the real answer.

RISC programs always contain fewer instructions than the equivalent CISC program.

False. RISC usually has more instructions (

N

larger) because one CISC line often expands into several loads/adds/stores; "Reduced" refers to instruction simplicity, not program length (see the left bar in figure s01).

A single CISC instruction always finishes in fewer cycles than the RISC sequence it replaces.

False. One rich CISC instruction can have a high CPI (many internal micro-ops), so the total cycle count is not automatically lower even though the instruction count is.

RISC forbids multiply, divide, or vector instructions entirely.

False. RISC-V and ARM have multiply/vector/crypto extensions; the defining rules are load/store separation + fixed-length encoding, not banning useful operations.

In a load/store architecture, ADD R1, R2, [MEM] is a legal instruction.

False. Arithmetic operands must all be registers; the memory value must first be brought in with a LOAD, then added (see the RISC column of figure s02).

Fixed-length encoding means every RISC instruction does the same amount of work.

False. Fixed length in bytes only makes instructions easy to fetch and decode in a pipeline; a shift and a multiply are the same 32 bits wide yet do very different work.

Modern x86 processors are pure CISC machines.

False. They are CISC on the outside but decode each instruction into RISC-like micro-ops run by an internally RISC-style core — a hybrid, exactly as figure s03 shows, per the Microcode and Micro-operations layer.

Lowering

N

is always the best way to speed up a program.

False. CPU time

= N \times CPI \times T_{c}

; shrinking

N

helps only if CPI and

T_{c}

don't grow to compensate — which is exactly the CISC failure mode (figure s01).

Every RISC ISA exposes exactly 32 general-purpose registers.

False. That is a common design goal (MIPS, RISC-V, ARMv8) but classic 32-bit ARM has only 16 integer registers and is still squarely RISC.

Microcode is a CISC-only concept and RISC cores never contain any.

False. Classic RISC used hardwired control for its simple instructions, but as figure s03's timeline shows, modern RISC cores still fall back to microcode/μops for rare complex instructions (and x86 back-ends run μops everywhere). The precise claim is: heavy reliance on microcode characterizes CISC, not that RISC has none at all.

Pipelining is possible only on RISC.

False. CISC is pipelined too (all modern x86 is), but fixed-length, load/store RISC instructions pipeline more easily and predictably, which was RISC's original advantage — compare the two columns of figure s02. See Pipelining.

Spot the error

Find the flawed reasoning in each statement.

"RISC is faster because it reduced the number of instructions in every program."

The error is "reduced the number of instructions" — RISC programs have more instructions. Speed comes from low CPI + short

T_{c}

+ easy pipelining, per the CPU Performance Equation.

"We should pick CISC because fewer instructions means the compiler has less work to do."

The error is treating compiler effort as the goal. RISC deliberately moves complexity into the compiler (Compiler Optimization); harder compiler work is the price paid to get simpler, faster hardware.

"CISC's variable-length instructions save memory, so CISC always beats RISC on real programs."

The error is "always." Code density is one axis; it ignores CPI and

T_{c}

. Smaller code that runs at high CPI on a slow clock can still lose on total time (recall the area in figure s01).

"Because x86 decodes to micro-ops, the CISC/RISC distinction is meaningless today."

The error is "meaningless." The distinction lives at the ISA design philosophy level (encoding, addressing modes, programmer-visible model) even when the silicon back-ends converge.

"A load/store architecture is slower because it needs extra LOAD and STORE instructions."

The error is equating "more instructions" with "slower." Those extra instructions are simple, single-cycle-ish, and pipeline well, so total time can still drop — the whole RISC bet.

"Adding more addressing modes always makes an ISA better because programmers get flexibility."

The error is ignoring cost: rich Addressing Modes complicate decoding and control, raising CPI and

T_{c}

— the RISC critique is that compilers rarely used most of them anyway.

Why questions

Short "why" reasoning — answer the mechanism, not just the label.

Why does fixed-length encoding make pipelining easier?

The fetch stage knows exactly where the next instruction starts without decoding the current one, so instructions stream through the pipeline at a steady rate (the even tiling in figure s02). See Instruction Encoding.

Why can RISC be faster even though

N_{R I S C} > N_{C I S C}

Because CPI drops toward 1 and

T_{c}

shrinks (simple hardwired control), and those two reductions multiply together to outweigh the larger

N

N \times CPI \times T_{c}

Why does allowing memory operands in arithmetic hurt pipelining?

One instruction now bundles a memory access and a computation, so it needs multiple cycles and stalls, breaking the clean one-stage-per-cycle flow that pipelines rely on.

Why did the CISC philosophy make sense in the 1970s but less so by the 1980s?

In the 1970s memory was scarce/expensive and code was hand-written, so dense powerful instructions paid off; by the 1980s cheap memory + smart compilers removed both pressures.

Why does CISC lean on microcode while RISC leans on hardwired control?

Complex multi-step instructions need an internal recipe (microcode) to sequence; RISC instructions are simple enough to control with direct combinational logic, which is faster.

Why does having many registers support the RISC style?

Registers keep operands out of memory, so the load/store model can do long arithmetic sequences without repeated slow memory trips — the point of registers, not their exact count. Related: x86 vs ARM.

Why isn't "make each instruction do more" a free win?

Doing more per instruction raises CPI and lengthens the critical path (larger

T_{c}

), so the time saved from a smaller

N

can be cancelled or reversed.

Edge cases

Boundary and degenerate scenarios the topic invites.

If a compiler is very poor, could a CISC design ever beat RISC?

Yes — RISC pushes complexity onto the compiler, so a weak compiler that schedules instructions badly can waste RISC's low-CPI potential, narrowing or erasing the gap.

What happens to the RISC advantage if CPI cannot be driven near 1 (e.g. many cache misses)?

The bet weakens: if stalls inflate effective CPI, RISC's larger

N

is no longer offset, so real memory behaviour, not just the ISA, decides the winner.

Is an ISA with fixed-length instructions but memory operands in arithmetic RISC or CISC?

It's a hybrid leaning CISC on the key axis — load/store separation is the more defining RISC trait than fixed length alone, so allowing memory arithmetic breaks the RISC model.

Consider a "RISC" chip that internally uses microcode for one rare instruction — is it still RISC?

Yes; philosophy is judged on the whole ISA (simple, load/store, fixed-length), not one exception. As figure s03 shows, even modern RISC cores keep a microcode path for rare complex ops without stopping being RISC.

What is the limiting case as CISC keeps decomposing every instruction into micro-ops?

It becomes RISC-on-the-inside: the visible ISA stays CISC but execution is RISC-like, which is exactly today's x86 — the two philosophies meet in the limit.

How do out-of-order and superscalar cores blur the CISC-vs-RISC trade-off further?

A superscalar core issues several μops per cycle and an out-of-order engine reorders them around stalls, so effective CPI can drop below 1 on both CISC and RISC front-ends — the raw ISA matters less because the back-end (which is RISC-like either way) is doing the heavy lifting.

Does out-of-order execution rescue a "bad" high-CPI CISC instruction?

Partly — reordering hides some latency by running independent μops during the stall, but a genuinely serial multi-μop instruction still occupies resources, so it improves throughput without erasing the underlying cost.

If two designs have identical CPU time, does the CISC-vs-RISC choice still matter?

Yes — it affects power, decoder area, code density, and how well the design scales with future compilers and pipelines, so equal time today doesn't mean equal engineering trade-offs.

Recall One-line summary of the traps

Almost every misconception collapses to forgetting that time $= N \times CPI \times T_{c}$ is a product (figure s01) — you cannot judge a philosophy by any single factor alone.