Question bank — Tomasulo's algorithm

False — it only removes false name dependencies (WAR/WAW). A true read-after-write dependency is a real flow of data, so the consumer genuinely must wait for the producer's CDB broadcast.

False — they can execute in any order. Ordering is enforced only on the register's final tag: whichever writer the register's tag currently names is the one whose broadcast is accepted; the other is simply ignored.

False — the RS snapshot is frozen at Issue. It waits for the specific tag it copied, so overwriting the register's tag afterwards (a WAR situation) cannot disturb it.

False — it broadcasts to everyone. Every RS and register listens simultaneously, because at Issue time the hardware cannot know how many future instructions will consume the value.

True — the RS latches the broadcast value and clears its Q field in that cycle, so with both Q fields now NULL it may start immediately without waiting for a fresh clock edge to "notice."

False — the classic algorithm has no ROB; it commits results directly to registers. An ROB is a later addition to also give precise exceptions and speculation recovery.

False — scoreboarding stalls a write until earlier reads finish (WAR stall); Tomasulo eliminates WAR entirely by renaming, so writers never wait on earlier readers.

False — a full RS pool is a structural hazard; the instruction stalls at Issue and blocks the in-order front end until a slot frees.

True — NULL tag means "no producer pending," so RegFile[r].value is the live value. A non-NULL tag means the register is an IOU waiting on that RS.

R1 accepts the broadcast only if R1's tag still equals Mult1. If a later instruction retagged R1 (say to Add2), R1 ignores Mult1's result — that older write was renamed away.

It is not ready. Execution requires both Qj = NULL and Qk = NULL; one missing operand (Qk still waiting on Add1) blocks it, because you cannot compute A + B without B.

Only when the source register's tag is NULL. If the source is still pending (tag set), we copy the tag, not a value — the value doesn't exist yet, so we record the IOU instead.

It changes nothing about unit latency (a DIV still takes its 40 cycles). It raises throughput by letting independent instructions overlap and start early, extracting ILP.

The destination tag is the RS's own name (like Add1), not the register name. That RS name is precisely the temporary rename that replaces the register name across the machine.

A single CDB is one broadcast channel per cycle — it is a structural bottleneck. If two units finish together, one must wait, which is why real designs may add multiple CDBs.

Because the producer may still be mid-execution. The tag is a forward-looking IOU that lets the consumer issue now and grab the value later off the CDB, keeping the pipeline flowing.

At Issue time the number of future consumers of a result is unknown (could be zero, could be five). A broadcast-and-latch scheme is simpler than maintaining a consumer list per producer.

Two instructions may target the same register; only the latest writer should win. The tag check lets the register accept only the broadcast whose RS name it currently holds, silently discarding the stale write.

If SUB's operands are ready and it gets its own RS, its false (name) dependency on the shared register is renamed away, so nothing forces it to wait for the earlier MUL. This is out-of-order execution in action.

A later writer gets a fresh RS tag, and the earlier reader already froze either the value or the old producing tag at Issue. The reader is immune to the register's tag changing, so the writer need not wait.

Because dependencies are resolved by tag matching, not register names. The RS name uniquely identifies one pending value, giving far more distinct names than the small architectural register set — that is hardware register renaming.

Both Q fields are set to NULL and both V fields loaded at Issue, so the instruction is immediately execute-ready and can start the very next cycle — no CDB wait at all.

The broadcast is harmless — it simply latches nowhere. This happens when a write was fully renamed over (a dead result), so the value is correctly discarded.

Both Qj and Qk hold that same tag; when the CDB broadcasts it, both fields match and are filled in the same cycle, then execution proceeds normally.

In the classic non-speculative algorithm this cannot arise, because tags are only set to live producers and cleared on broadcast; deadlock-free progress relies on every set tag eventually broadcasting.

Yes — each write gets a distinct RS tag at its own Issue, and each reader froze the tag valid at its Issue moment, so read/write ordering is preserved purely by the tag snapshots.

The finished result waits (arbitration for the shared bus); its RS stays busy until it wins the CDB, which can delay dependent instructions — a real structural limit of a single-CDB design.