One way to solve the data hazards is by using pipeline stalls or bubbles. As instructions are fetched, control logic determines whether a hazard could/will occur. If this is true, then the control logic inserts
nops into the pipeline where nop is a MIPS instruction that does no operation to change state.
Before the next instruction (which would cause the hazard) is executed, the previous one will have had sufficient time to complete and prevent the hazard.
The figure shows the data hazard (dashed lines) caused by reading $2 after writing it.
It is solved by pipeline stalls.
|
|
The
and instruction can not fetch $2 until clock cycle 5, so the and instruction remains in the IF/ID register until clock cycle 5.
Clock cycles 3 and 4 become two bubbles, which can be implemented by inserting two nop instructions between instructions sub and and as follows.
sub $2, $1, $3
and $4, $2, $5
or $6, $3, $2
|
⇒ Inserting two bubbles/ nops
|
sub $2, $1, $3 nop nop and $4, $2, $5 or $6, $3, $2 |
nops is not practical because it requires the prediction of data hazards when fetching an instruction.
Insertion of bubbles is more practical and will be discussed later.
After insertion of the bubbles, all the dependences go forward in time and no further hazards occur.
If the number of nops is equal to the number of stages in the pipeline, the processor has been cleared of all instructions and can proceed free from hazards.
This is called flushing the pipeline.
|
“Death, therefore, the most awful of evils, is nothing to us, seeing that, when we are, death is not come, and, when death is come, we are not.” ― Epicurus |