Question bank — Hazard mitigation — stalling, forwarding - bypassing, branch prediction

False. It kills every ALU-producer RAW, but a lw result is only born at the end of MEM while the very next instruction needs it in EX — one cycle earlier in real time. You cannot forward into the past, so load-use still costs ≥1 stall.

True in principle — one pair could contend for the register file (structural) and have a RAW dependency (data). They are independent failure modes; classic MIPS avoids the register-file structural clash by writing in the first half of the cycle and reading in the second.

False. Removing a necessary stall gives a wrong answer, but if forwarding already supplies the value, the stall is redundant and removing it is both correct and faster. The stall is only mandatory when no wire can deliver the value in time.

False. "~50%" is a rough average over random branches; real code has loop back-edges (mostly taken) and error checks (mostly not-taken), so a static not-taken predictor's accuracy is workload-dependent and often worse than 50% on loop-heavy code.

False. It requires two wrong-in-a-row before it flips its prediction — so it absolutely can mispredict twice consecutively (e.g. a branch that suddenly reverses its long-run behavior). The hysteresis just prevents a single anomaly from flipping it.

False. The penalty equals the number of stages between fetch and the point of resolution. Resolving a branch earlier (e.g. in ID instead of EX) shrinks the penalty even with the same total depth.

True. In $\text{CPI}=1+b\cdot m\cdot p$, setting $m=0$ zeroes the penalty term for any $b$ and $p$. Perfect prediction hides branches entirely — at least in this simple model.

Missing two guards: you must also check MEM/WB.RegWrite (the instruction actually writes a register) and rd ≠ 0 (register $zero is never a real destination). Forwarding a non-writing or $zero result corrupts the ALU input.

Backwards. Program order says the most recent write before you is the correct one, and that value sits in the closer EX/MEM latch. The newest-wins rule gives EX/MEM priority; MEM/WB only forwards when the EX-hazard condition is false.

Wrong count. With forwarding, we only wait until the value exists (end of MEM), then bypass it into EX. The gap between "available end of MEM" and "needed start of EX" is a single cycle → exactly 1 bubble, not 3.

Incomplete. Stalling needs three coordinated actions: disable the PC write, disable the IF/ID write (freeze the decoded instruction), and inject a bubble by zeroing the ID/EX control signals. Freeze without a bubble lets the stale instruction advance and do damage.

No — that describes stalling. Predict-not-taken keeps actively fetching the fall-through path speculatively; it only flushes those instructions if the branch turns out taken. Doing nothing wastes cycles even when the guess would have been right.

The delay slot is always executed, but the compiler can fill it with a genuinely useful independent instruction (see Compiler instruction scheduling), turning the would-be penalty into productive work. It's only wasted if no such instruction exists (fill with NOP).

The ALU result exists at the end of EX — the same cycle the consumer sits in EX, so a wire delivers it in time. The load result exists only at the end of MEM, which is one cycle after the consumer's EX, and no wire can move data backward in time.

Decode must read operands early to feed EX, and the result isn't ready to write until the very end (after MEM for loads). This read-early/write-late split is what makes an earlier instruction's write lag a later instruction's read — the structural root of every RAW hazard.

A loop back-edge is taken every iteration except the last. A 1-bit predictor flips on that single not-taken exit and then mispredicts again on re-entry — two misses per loop. The 2-bit counter's hysteresis absorbs the lone exit, keeping its long-run "taken" guess intact.

They are conditional stages of one event: a cycle is lost only if the instruction is a branch (fraction $b$) and it is mispredicted (probability $m$), and then it costs $p$ cycles. Independent probabilities compound multiplicatively; the product is added to the ideal CPI of 1.

Past 2 bits, a simple saturating counter captures little extra pattern while its larger table increases aliasing (different branches mapping to the same counter). The added state costs area and hurts accuracy through interference — diminishing returns beyond the hysteresis 2 bits already provide.

Correctness is cheap; throughput is the goal. Stalling guarantees the right answer by simply waiting, but every bubble is a lost instruction slot — it sacrifices the whole point of pipelining (1 instruction/cycle) to avoid needing clever hardware.

Never. $zero is hard-wired to 0 and is never a meaningful result, so all forwarding conditions explicitly require rd ≠ 0. Forwarding it would overwrite a correct zero with garbage in the ALU input mux.

The consumer of the second lw (not the first lw itself) is what stalls; the second lw doesn't read the first's value in EX, it just writes its own. A load-use stall is triggered by the use in the following instruction's EX, so count stalls per use, not per load.

In this simple model, no — a correct prediction fetches the right path continuously with zero flush, so its penalty term is 0. (Real machines may still pay a small BTB/target-fetch cost, but the classic CPI model treats a correct prediction as free.)

With $b=1$ and $m=0$, $\text{CPI}=1+1\cdot 0\cdot p=1$. Perfect prediction makes even an all-branch program run at ideal throughput; branch frequency only matters when predictions are wrong.

No — that stall is mandatory, not redundant. Forwarding handles the value once it exists (end of MEM), but the one-cycle bubble is still required to align that availability with the consumer's EX. Correct designs do both together.

Yes. A branch instruction can depend on a register value still in flight (data hazard resolving its condition) while the pipeline simultaneously doesn't know the next PC (control hazard). They stack, and the total penalty is the combination of the stall/flush each demands.