Question bank — Out-of-order execution — Tomasulo algorithm (conceptual)

False — Issue is strictly in program order; only Execute and Write may reorder, and even then RAW dependencies are honored, so the order is constrained, not random.

False — Issue being in order just assigns names/tags quickly; the Execute stage runs whatever has its operands ready, so independent instructions behind a slow load still fire and hide its latency.

False — the renaming in Tomasulo is implicit: results are named by RS tags, which are internal hardware names invisible to the program. See Register Renaming.

False — the CDB is a single shared bus, one (tag, value) per cycle; simultaneous finishers must arbitrate and one waits, a genuine structural bottleneck.

False — it remembers either the operand's value (Vj/Vk) or the producing RS's tag (Qj/Qk); the architectural register number is discarded, and that discarding is the renaming.

False — plain Tomasulo writes results out of order and has no in-order commit point; precise exceptions require adding a Reorder Buffer (ROB).

False — Execute waits until Qj == 0 && Qk == 0; you literally cannot start until both real values have arrived, which is exactly how RAW is enforced.

False — one CDB broadcast; all five RS entries snoop it simultaneously. Broadcast is one-to-many for free.

False — they are false dependencies caused only by name reuse; renaming dissolves them, and only RAW (the true dependency) survives.

False — RAW is respected and in-order Issue enforces "last writer wins," so the architectural outcome is identical to sequential execution.

Error — we do not stall Issue for a data-not-ready operand; we issue it and record the producer's tag in Qj. Only a lack of free RS (structural) stalls Issue.

Error — Add1 broadcasts on the CDB and Mult1 snoops the value directly into Vj. The value flows tag-to-RS without a round trip through the register file (register-to-register forwarding).

Error — Add1's broadcast is ignored for the register because Qi[F6] != Add1 anymore; the stale write silently drops. This is how WAW is solved automatically.

Error — I2 grabbed F8's value (Vk) at issue because it was ready; a later write of F8 lands in a different RS tag and cannot touch I2's captured copy. That is WAR being neutralized.

Error — per operand it is one or the other: a valid tag (Qj != 0, not yet ready) or a valid value (Qj == 0, ready). The tag is cleared the instant the value is captured.

Error — Issue is in order; no free RS is a structural stall that blocks Issue entirely. Reordering happens at Execute, not Issue.

Error — Qi stores the tag of the RS that will next write that register (or "ready" if a real value sits in the register file). The value lives in the register file, not in Qi.

Error — memory ordering is not automatically free; loads/stores use load/store buffers and must respect memory dependencies through their address field A. See Cache Misses & Memory Latency.

Because by the time the value is ready the register may have been renamed by a newer writer; the tag names the exact producer, so the right value is captured regardless of later reuse.

In-order Issue is what lets renaming preserve "last writer wins" for each register (Qi always reflects the latest issuer), keeping the architectural result correct despite out-of-order execution.

Every result-producing unit competes for one broadcast slot per cycle; in a wide Superscalar Execution machine many results finish together and serialize on the CDB, motivating multiple CDBs.

Readers capture their producer's tag (or value) at Issue time; a later writer gets a brand-new tag, so it physically cannot overwrite something an earlier reader already recorded.

Because a produced value may be needed by waiting RS entries (to fire the next instruction) and must update the architectural register state — one broadcast serves both consumers at once.

There is no separate physical register file being allocated by name; the RS tags themselves act as the fresh names, so renaming falls out of the buffering mechanism rather than a dedicated rename table. Contrast with explicit Register Renaming.

Scoreboarding tracks register names without renaming, so it must stall on anti/output hazards; Tomasulo's tag-based renaming removes the name conflict, leaving only the genuine RAW to enforce.

With Branch Prediction & Speculation the machine issues down the predicted path; classic Tomasulo executes those, but recovering cleanly on a mispredict again needs a Reorder Buffer (ROB) to squash wrong-path results.

Then Qj == 0 and Qk == 0 immediately; the instruction can move to Execute as soon as the functional unit is free — no waiting, no tags needed.

The unused operand slot is simply marked ready (Qk == 0 with a don't-care value), so the fire condition Qj == 0 && Qk == 0 isn't blocked by a nonexistent operand.

The CDB broadcast still updates the register file if Qi[dest] still equals that tag; if not even the register wants it (renamed away), the value is simply written to no one — harmless. The RS is freed either way.

Qi[dest] ends pointing at the second (later) writer; the slow first writer's eventual broadcast is ignored for the register — WAW resolved, and the register ends with the correct last value.

The RS captures the CDB value in the write cycle and can begin Execute the next cycle; it cannot both snoop and start in the same cycle because the value arrives at cycle's end.

Structural stall at Issue — the pipeline front end freezes for that op (and everything behind it, since Issue is in order) until a matching RS frees up.

The register file still updates (state must stay correct in case a later instruction reads it), but no RS snoops it; the update is invisible to execution until someone reads that register.

Correctness holds because those independents had no RAW on the load; the load's result flows to whoever tagged it, and in-order Issue guarantees the final register state matches sequential order. This is exactly the latency-hiding win over strict Pipelining and Hazards.