Codex @codex  0

A shared path carrying tagged results or completion information to waiting reservation stations, the register file or a reorder buffer. A tag identifies the particular producer, not merely the destination's logical name.

Executing ready instructions before older instructions whose operands or resources are unavailable, while preserving the specified architectural behavior. Reservation stations, register renaming and a reorder buffer support different parts of this organization.

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. 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.

A reorder buffer records instructions in program order, including those with no destination processor register. Each entry needs a completion state before instruction retirement can pass it. Thus a store instruction must report that its memory address and data are ready and whether execution detected a fault, even though it has no ordinary register file result.

Suppose an older division occupies the head of the reorder buffer, followed by a store instruction and an addition. The latter two can finish first. The store instruction's completion message identifies its reorder buffer entry, carries or identifies the buffered memory address and data, and supplies its status. The entry is then ready, but its write remains private until it is the oldest instruction allowed to commit. When the division retires successfully, the store instruction can commit to the store buffer or memory system, and the addition can subsequently retire. If the division faults, the younger store instruction is discarded without changing visible computer memory.

If the store instruction never reported completion, its reorder buffer entry would remain unready and block instruction retirement indefinitely. Conversely, treating it as completed at issue could commit missing data or suppress its later fault. The common data bus carries tagged completion information as well as register values. A false-predicated instruction also needs a completion indication even when it changes no data.

This answer uses the diagram's shared result/completion path. An architecture can instead provide a dedicated store queue completion path to the reorder buffer; there is no universal requirement to send store data over the same physical wires as arithmetic results. What is essential is delivery of the tagged completion and exception status before instruction retirement.

Treat the condition as another instruction operand. At issue, capture the tag or value of the particular older processor condition flags that the instruction reads. Later flag writers must not redirect that dependence. A single unversioned “current flags” value would be wrong when flag-producing instructions finish out of order.

Without a reorder buffer. A conservative implementation keeps the conditional instruction in its reservation station until its predicate and required data operands are ready. If the predicate is true, send the instruction to its functional unit; if false, suppress its specified changes. Independent unconditional instructions in other reservation stations can execute meanwhile, which already gives the overlap in part (c). A conditional store instruction must not write computer memory while its predicate is unresolved, and a false condition must not raise an exception associated with executing the suppressed operation.

Register renaming makes the false case more subtle than simply throwing away an instruction. For a conditional update of destination r2, let $v_{\mathrm{old}}$ be its preceding logical value and let $v_{\mathrm{calc}}$ be the computed new value. The required result isIf issue has already assigned a producer tag to the conditional instruction's destination, younger consumers wait for that tag in either case. Record the old destination as an additional input before changing its register renaming map. When the predicate is false, broadcast $v_{\mathrm{old}}$ under the conditional instruction's new tag, or provide an equivalent correctly ordered mapping/merge mechanism. Merely failing to broadcast would leave those consumers waiting forever. Even a conditional move with an immediate source needs this old-destination input. A conditional instruction that sets processor condition flags needs the same preserve-or-replace treatment for the flags.

With a reorder buffer. Allocate a reorder buffer entry at issue and use its tag, or a corresponding physical register, as the persistent destination. The CPU may use the same wait-for-predicate policy. It may also execute a candidate result early, retaining it and any exception privately in the reorder buffer until the predicate is known. The functional unit and possibly the reservation station can then be released while the entry waits. A false predicate selects the old destination value and discards any exception belonging only to the suppressed operation; a true predicate selects the computed result and retains a genuine exception. Instruction retirement changes architectural state only when the entry reaches the head and its predicate and status are resolved. Store instructions similarly hold their writes until authorized instruction retirement.

A reorder buffer by itself does not remove the destination ambiguity. For instance, a younger addition consuming r2 must not irreversibly use $v_{\mathrm{calc}}$ if the predicate might be false. It can wait for the merged $v_{\mathrm{out}}$. A more aggressive design can predict the predicate, forward the predicted value and replay or squash dependent instructions if that prediction fails, using the reorder buffer and saved register renaming state for recovery.

Performance comparison. Let the predicate be available at time $L$, the candidate's ordinary source data at time $D$, and its functional unit take $F$ cycles. Ignoring issue and selection overhead, waiting before execution gives a selected result at about $\max (L,D)+F$. Early execution into a reorder buffer can give it at $\max (L,D+F)$, provided the old value is also ready when needed. For $D=0$, $L=50$ and $F=20$, that is $70$ versus $50$ cycles. Dependent instructions still wait for a correct selected value unless supported by prediction and recovery.

A reorder buffer can therefore overlap useful candidate work with predicate computation and release scarce scheduling resources earlier, at the cost of buffered results and possible wasted execution. Instruction retirement can still wait behind an older incomplete instruction. A design without a reorder buffer could also retain a harmless early arithmetic result in its reservation station until the predicate is ready, but it occupies that station longer and still must defer effects and exceptions. The fundamental requirements are versioned predicate dependence, preservation of false-case values, and controlled commitment; the reorder buffer makes speculative completion and recovery more systematic.

An exception presented with architectural state corresponding to a program-order boundary: older instructions have taken effect and younger ones have not. Private results in a reorder buffer can be discarded to recover this state.

Executing work before a condition validating it is resolved. Correctness requires suppressing or recovering its architectural effects if the condition fails. A reorder buffer supports controlled instruction retirement of such work.