Consider the pipelined execution of these
instructions:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ||
| ADD | R1, R2, R3 | IF | ID | EX | MEM | WB | ||||
| SUB | R4, R5, R1 | IF | IDsub | EX | MEM | WB | ||||
| AND | R6, R1, R7 | IF | IDand | EX | MEM | WB | ||||
| OR | R8, R1, R9 | IF | IDor | EX | MEM | WB | ||||
| XOR | R10,R1,R11 | IF | IDxor | EX | MEM | WB |
All the instructions after the ADD use the result of the ADD instruction (in R1). The ADD instruction writes the value of R1 in the WB stage (shown black), and the SUB instruction reads the value during ID stage (IDsub). This problem is called a data hazard. Unless precautions are taken to prevent it, the SUB instruction will read the wrong value and try to use it.
The AND instruction is also affected by this data hazard. The write of R1 does not complete until the end of cycle 5 (shown black). Thus, the AND instruction that reads the registers during cycle 4 (IDand) will receive the wrong result.
The OR instruction can be made to operate without incurring a hazard by a simple implementation technique. The technique is to perform register file reads in the second half of the cycle, and writes in the first half. Because both WB for ADD and IDor for OR are performed in one cycle 5, the write to register file by ADD will perform in the first half of the cycle, and the read of registers by OR will perform in the second half of the cycle.
The XOR instruction operates properly, because its register read occur in cycle 6 after the register write by ADD.
The next page discusses forwarding, a technique to eliminate the stalls for the hazard involving the SUB and AND instructions.
We will also classify the data hazards and consider the cases when stalls can not be eliminated. We will see what compiler can do to schedule the pipeline to avoid stalls.