Main Page | See live article | Alphabetical index

Hazard (computer architecture)

In computer architecture, a hazard is a potential problem that can happen in a pipelinedd 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.

Table of contents
1 Data Hazards
2 Structural Hazards
3 Branch Hazards
4 Eliminating Hazards

Data Hazards

Data hazards occur when data is modified. There are three situations it can occur in:
  1. 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.
  2. Write after Read (WAR)
  3. 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 occur when the processor is told to branch - IE, if a certain condition is true, jump from one part of the instructions 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 (a) preventing hazards from occurring, or (b) working around them if they do.

Forwarding

Forwarding is used to work around data hazards. It involves feeding output data into a previous stage of the pipeline.

For instance, if we write the value 3 register 1, (which already contains a 6), and then add 7 to register 1 and store the result in 2. Following execution, register 2 should contain the value 10. However, because the second instruction 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.

Bubbling the Pipeline

Bubbling the pipeline (a technique also known as a pipeline break or pipeline stall) is a method for preventing branch and structural 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 be suffeciently complete to 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.