Instruction-level parallelism - page 4

The left side sequence seems the "natural" translation. A simple compiler, reading sequentially, might translate each line of code into its corresponding three instructions. 

In both versions, the six instructions of the form "X => device" are all 1 tu instructions. They are just "dropping off" data to be operated on.

And in both versions, it is only the three instructions "multiplier/adder/divider => P/Q/R" that could possibly experience any wait.

But on the right side version, we have moved those three instructions to the end. When we get to the first of the three, "multiplier => P", we will have to wait. But while we are waiting, ALL THREE DEVICES ARE SIMULTANEOUSLY RUNNING.

If we assume that all three take about the same amount of time, then by the time the multiplier is done, so too will the adder and divider be done, and the final two instructions will take just 1 tu each.

No matter what their relative timing, the total wait for the last three instructions on the right side will be equal to the delay of the slowest of the three -- instead of the sum of the three as on the left side.

This is what traditional systems call "out of order" or "OoO" instruction processing. But because their instructions are "atomic", they cannot split an operation as we have done, to store the inputs first and retrieve the output later. Instead, they try to do this with specialized hardware, which has a *tremendous* cost in area and power (more on this shortly).