Hazard (computer architecture)
|
In computer architecture, a hazard is a potential problem that can happen in a pipelined processor. There are typically three types of hazards: data hazards, branching hazards, and structural hazards.
Instructions in a pipelined processor are performed in several stages, so that at any given time several instructions are being executed, and instructions may not be completed in desired order.
A hazard occurs when two or more of these simultaneous (possibly out of order) instructions conflict.
Contents |
Data Hazards
Data hazards occur when data is modified. There are three situations it can occur in:
- Read after Write (RAW): Memory is modified and read soon after. Because the first instruction may not have finished writing to memory, the second instruction may use incorrect data.
- Write after Read (WAR): Read from a memory location and write soon after to that location. Because the write may have finished before the read, the read instruction may get incorrectly the new written value.
- Write after Write (WAW): Two instrutions that write to memory are performed. The first one issued may finish second, and therefore leave the memory with an incorrect data value.
Structural Hazards
A structural hazard occurs when a part of the processor's hardware is needed by two or more instructions at the same time. A structural hazard might occur, for instance, if a program were to execute a branch instruction followed by a computation instruction. Because they are executed in parallel, and because branching is typically slow (requiring a comparison, program counter-related computation, and writing to registers), it is quite possible (depending on architecture) that the computation instruction and the branch instruction will both require the ALU at the same time.
Branch Hazards
Branching hazards (also known as control hazards) occur when the processor is told to branch - IE, if a certain condition is true, jump from one part of the instruction stream to another one - not necessarily the next one sequentially. In such a case, the processor cannot tell in advance whether or not it should process the next instruction (when it may instead have to move to a distant instruction).
This can result in the processor doing unwanted actions.
Eliminating Hazards
There are several established techniques for either preventing hazards from occurring, or working around them if they do.
- Bubbling the Pipeline
- Bubbling the pipeline (a technique also known as a pipeline break or pipeline stall) is a method for preventing data, structural, and branch hazards from occurring. As instructions are fetched, control logic determines whether or not a hazard could/will occur. If this is true, then the control logic inserts NOPs into the pipeline. Thus, before the next instruction (which will cause the hazard) is executed, the previous one will have had sufficient time to complete and prevent the hazard. 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. All forms of stalling introduce a delay before the processor can resume execution.
Eliminating Data Hazards
- Forwarding
- Forwarding involves feeding output data into a previous stage of the pipeline. For instance, let's say we want to write the value 3 to register 1, (which already contains a 6), and then add 7 to register 1 and store the result in register 2. Following execution, register 2 should contain the value 10. However, because the first instruction (write 3 to register 1) has not yet executed completely, the second instruction (register 1 + 7 -> register 2) adds 7 to the old value (6), register 2 would contain 13 instead. To prevent this, we feed back the output of the first instruction (3) into the previous stage(s) of the pipeline. That stage of the pipeline now has two inputs - the new value from the next stage (3) and the old, unwanted value from the previous stage (6). Therefore, it is necessary to add add control logic to determine which input to use.
- Register renaming