= Solution
In the illustrated <out-of-order execution> scheme without a <reorder buffer>, a <reservation station> identifier acts as the producer tag for an outstanding result. A <register renaming> map and waiting operands in other <reservation stations> can refer to that tag. The tag must remain unique until the result has been broadcast and the required <register file> update has occurred.
For example, issue a slow multiplication producing `r1` into <reservation station> S, then an addition `r4 := r1 + r5` into another <reservation station>. The addition records S as the unresolved source of `r1`. Even after the multiplier has accepted its operands, the multiplication can take many cycles; S cannot be reassigned merely because its operands have left the <reservation station>. If an independent short instruction is assigned S and broadcasts first, the addition would mistake that unrelated value for the multiplication's result. A later multiplication result could likewise corrupt the new instruction's <register renaming> mapping.
Finishing execution is also insufficient if the result is waiting for <common data bus> access: consumers and the <register file> still name S until writeback. \b[Keep the producer tag allocated through broadcast/writeback, so no younger result can masquerade as the outstanding producer.] With a separate persistent producer tag, such as a <reorder buffer> entry or a <physical register>, a design can release the scheduling slot earlier; this changes the tag-ownership arrangement in the question.
$$
\boxed{\text{Do not reuse a producer tag before its result has been broadcast.}}
$$
Back to article page
