Reorder Buffer commit

Question

When having an Out-of-Order execution processor with a reorder buffer (ROB) and branch speculation, I understand that the changes are not being made until the ROB has performed a commit.

The results of the functional units (FUs) write their result on lets say a common data bus (CDB) and on the ROB when finished executing. The ROB can then decide if the branch was successfully predicted and if so commit otherwise the ROB is flushed.

What I don't understand is what happens to the reservation station updates that came from the CDB broadcasts of the FUs, should they not be flushed/rolled back somehow?

An example I can up with (maybe not the best)

addi $s1, $zero, 8
addi $s2, $zero, 9

addi $s3, $zero, 0
bneq $s1, $s2, L1
addi $s3, $s3, 1     // first increment
L1:
addi $s3, $s3, 2     // second increment

$s3 is initialized to 0, then a miss-prediction of the branch causes $s3 to increase by 1. The result is broadcasted to the RSs.

$s3 is now ready to start executing for the second increment of 2. At the same time the branch miss-prediction is detected and the ROB is flushed, however the RS of the adder is not changed, so $s3 now has a wrong value and was never in the ROB to be flushed.

How is this solved?

I suspect that I am missing something crucial, I am not very experienced, I just graduated and came up with this while revising.

Answer 1

As I understand it, on Intel CPUs at least, the ROB tracks all in-flight instructions inside the out-of-order part of the pipeline, including ones that are still in the RS waiting to execute. So instructions are added to both the ROB and the RS when they issue into the out-of-order part of the core.

I think this design is nearly universal. You're right that you need to be able to keep track of every instruction that's still speculative somehow.

---

Also, all instructions that depend on instructions discovered to have been mis-speculated need to be flushed. It's certainly easier to flush the whole ROB as you describe, and get back to the last non-speculative state.

So even though the second add still needs to be executed, the mis-speculation means its input might be wrong. So it needs to be flushed, to avoid exactly the problem you're talking about.