{"history":[],"article":{"id":"7372779a-261f-49cd-9662-5cd3a5eb08b5","title":"Hazard (computer architecture)","slug":"hazard-computer-architecture","content":":::summary\n:::\n\n# \nIn the domain of [central processing unit](https://bliptext.com/articles/central-processing-unit) (CPU) [design](https://bliptext.com/articles/cpu-design), **hazards** are problems with the [instruction pipeline](https://bliptext.com/articles/instruction-pipeline) in CPU [microarchitectures](https://bliptext.com/articles/microarchitecture) when the next instruction cannot execute in the following clock cycle, and can potentially lead to incorrect computation results.\nThree common types of hazards are data hazards, structural hazards, and control hazards (branching hazards).\nThere are several methods used to deal with hazards, including [pipeline stalls](https://bliptext.com/articles/pipeline-stall)/pipeline bubbling, [operand forwarding](https://bliptext.com/articles/), and in the case of [out-of-order execution](https://bliptext.com/articles/out-of-order-execution), the [scoreboarding](https://bliptext.com/articles/scoreboarding) method and the [Tomasulo algorithm](https://bliptext.com/articles/tomasulo-algorithm).\n\n# Background\n[Instructions](https://bliptext.com/articles/instruction-computer-science) in a pipelined processor are performed in several stages, so that at any given time several instructions are being processed in the various stages of the pipeline, such as fetch and execute.\nThere are many different instruction pipeline [microarchitectures](https://bliptext.com/articles/microarchitecture), and instructions may be [executed out-of-order](https://bliptext.com/articles/out-of-order-execution).\nA hazard occurs when two or more of these simultaneous (possibly out of order) instructions conflict.\n\n# Types\n\n## Data hazards\nData hazards occur when instructions that exhibit data dependence modify data in different stages of a pipeline.\nIgnoring potential data hazards can result in [race conditions](https://bliptext.com/articles/race-condition) (also termed race hazards).\nThere are three situations in which a data hazard can occur:\nRead after read (RAR) is not a hazard case.\nConsider two instructions i1 and i2, with i1 occurring before i2 in program order.\n\n### Read after write (RAW)\n(i2 tries to read a source before i1 writes to it)\nA read after write (RAW) data hazard refers to a situation where an instruction refers to a result that has not yet been calculated or retrieved.\nThis can occur because even though an instruction is executed after a prior instruction, the prior instruction has been processed only partly through the pipeline.\n\n#### Example\nFor example:\ni1.\n**R2** <- R5 + R8 i2.\nR4 <- **R2** + R8\nThe first instruction is calculating a value to be saved in register R2, and the second is going to use this value to compute a result for register R4.\nHowever, in a [pipeline](https://bliptext.com/articles/pipeline-computing), when operands are fetched for the 2nd operation, the results from the first have not yet been saved, and hence a data dependency occurs.\nA data dependency occurs with instruction i2, as it is dependent on the completion of instruction i1.\n\n### Write after read (WAR)\n(i2 tries to write a destination before it is read by i1)\nA write after read (WAR) data hazard represents a problem with concurrent execution.\n\n#### Example\nFor example:\ni1.\nR4 <- R1 + **R5**\ni2.\n**R5** <- R1 + R2\nIn any situation with a chance that i2 may finish before i1 (i.e., with concurrent execution), it must be ensured that the result of register R5 is not stored before i1 has had a chance to fetch the operands.\n\n### Write after write (WAW)\n(i2 tries to write an operand before it is written by i1)\nA write after write (WAW) data hazard may occur in a [concurrent execution](https://bliptext.com/articles/concurrent-computing) environment.\n\n#### Example\nFor example:\ni1.\n**R5** <- R4 + R7 i2.\n**R5** <- R1 + R3\nThe write back (WB) of i2 must be delayed until i1 finishes executing.\n\n## Structural hazards\nA structural hazard occurs when two (or more) instructions that are already in pipeline need the same resource.\nThe result is that instruction must be executed in series rather than parallel for a portion of pipeline.\nStructural hazards are sometimes referred to as resource hazards.\nExample:\nA situation in which multiple instructions are ready to enter the execute instruction phase and there is a single ALU (Arithmetic Logic Unit).\nOne solution to such resource hazard is to increase available resources, such as having multiple ports into main memory and multiple ALU (Arithmetic Logic Unit) units.\n\n## Control hazards (branch hazards or instruction hazards)\nControl hazard occurs when the pipeline makes wrong decisions on branch prediction and therefore brings instructions into the pipeline that must subsequently be discarded.\nThe term branch hazard also refers to a control hazard.\n\n# Eliminating hazards\n\n## Generic\n\n### Pipeline bubbling\nBubbling the pipeline, also termed a pipeline break or pipeline stall, is a method to preclude data, structural, and branch hazards.\nAs instructions are fetched, control logic determines whether a hazard could/will occur.\nIf this is true, then the control logic inserts no operations (NOPs) into the pipeline.\nThus, before the next instruction (which would cause the hazard) executes, the prior one will have had sufficient time to finish and prevent the hazard.\nIf the number of NOPs equals the number of stages in the pipeline, the processor has been cleared of all instructions and can proceed free from hazards.\nAll forms of stalling introduce a delay before the processor can resume execution.\nFlushing the pipeline occurs when a branch instruction jumps to a new memory location, invalidating all prior stages in the pipeline.\nThese prior stages are cleared, allowing the pipeline to continue at the new instruction indicated by the branch.\n\n## Data hazards\nThere are several main solutions and algorithms used to resolve data hazards:\nIn the case of [out-of-order execution](https://bliptext.com/articles/out-of-order-execution), the algorithm used can be:\nThe task of removing data dependencies can be delegated to the compiler, which can fill in an appropriate number of NOP instructions between dependent instructions to ensure correct operation, or re-order instructions where possible.\n\n### Operand forwarding\n\n### Examples\nFor example, 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, i.e.:\ni0: R1 = **6**\ni1: R1 = **3**\ni2: R2 = R1 + **7** = **10**\nFollowing execution, register 2 should contain the value **10**.\nHowever, if i1 (write ****3**** to register 1) does not fully exit the pipeline before i2 starts executing, it means that R1 does not contain the value ****3**** when i2 performs its addition.\nIn such an event, i2 adds **7** to the old value of register 1 (**6**), and so register 2 contains **13** instead, i.e.:\ni0: R1 = **6**\ni2: R2 = R1 + **7** = **13**\ni1: R1 = **3**\nThis error occurs because i2 reads Register 1 before i1 has committed/stored the result of its write operation to Register 1.\nSo when i2 is reading the contents of Register 1, register 1 still contains **6**, not **3**.\nForwarding (described below) helps correct such errors by depending on the fact that the output of i1 (which is ****3****) can be used by subsequent instructions before the value ****3**** is committed to/stored in Register 1.\nForwarding applied to the example means that there is no wait to commit/store the output of i1 in Register 1 (in this example, the output is **3**) before making that output available to the subsequent instruction (in this case, i2). The effect is that i2 uses the correct (the more recent) value of Register 1: the commit/store was made immediately and not pipelined.\nWith forwarding enabled, the Instruction Decode/Execution (ID/EX) stage of the pipeline now has two inputs: the value read from the register specified (in this example, the value **6** from Register 1), and the new value of Register 1 (in this example, this value is **3**) which is sent from the next stage Instruction Execute/Memory Access (EX/MEM).\nAdded control logic is used to determine which input to use.\n\n## Control hazards (branch hazards)\nTo avoid control hazards microarchitectures can:\nIn the event that a branch causes a pipeline bubble after incorrect instructions have entered the pipeline, care must be taken to prevent any of the wrongly-loaded instructions from having any effect on the processor state excluding energy wasted processing them before they were discovered to be loaded incorrectly.\n\n## Other techniques\nMemory latency is another factor that designers must attend to, because the delay could reduce performance.\nDifferent types of memory have different accessing time to the memory.\nThus, by choosing a suitable type of memory, designers can improve the performance of the pipelined data path.\n\n## General","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-25T19:25:40.083Z","updated_at":"2025-01-25T19:25:40.083Z","search_vector":"'architectur':3 'comput':2 'hazard':1","search_content":" \n \n\n# \nIn the domain of [central processing unit](https://bliptext.com/articles/central-processing-unit) (CPU) [design](https://bliptext.com/articles/cpu-design), **hazards** are problems with the [instruction pipeline](https://bliptext.com/articles/instruction-pipeline) in CPU [microarchitectures](https://bliptext.com/articles/microarchitecture) when the next instruction cannot execute in the following clock cycle, and can potentially lead to incorrect computation results.\nThree common types of hazards are data hazards, structural hazards, and control hazards (branching hazards).\nThere are several methods used to deal with hazards, including [pipeline stalls](https://bliptext.com/articles/pipeline-stall)/pipeline bubbling, [operand forwarding](https://bliptext.com/articles/), and in the case of [out-of-order execution](https://bliptext.com/articles/out-of-order-execution), the [scoreboarding](https://bliptext.com/articles/scoreboarding) method and the [Tomasulo algorithm](https://bliptext.com/articles/tomasulo-algorithm).\n\n# Background\n[Instructions](https://bliptext.com/articles/instruction-computer-science) in a pipelined processor are performed in several stages, so that at any given time several instructions are being processed in the various stages of the pipeline, such as fetch and execute.\nThere are many different instruction pipeline [microarchitectures](https://bliptext.com/articles/microarchitecture), and instructions may be [executed out-of-order](https://bliptext.com/articles/out-of-order-execution).\nA hazard occurs when two or more of these simultaneous (possibly out of order) instructions conflict.\n\n# Types\n\n## Data hazards\nData hazards occur when instructions that exhibit data dependence modify data in different stages of a pipeline.\nIgnoring potential data hazards can result in [race conditions](https://bliptext.com/articles/race-condition) (also termed race hazards).\nThere are three situations in which a data hazard can occur:\nRead after read (RAR) is not a hazard case.\nConsider two instructions i1 and i2, with i1 occurring before i2 in program order.\n\n### Read after write (RAW)\n(i2 tries to read a source before i1 writes to it)\nA read after write (RAW) data hazard refers to a situation where an instruction refers to a result that has not yet been calculated or retrieved.\nThis can occur because even though an instruction is executed after a prior instruction, the prior instruction has been processed only partly through the pipeline.\n\n#### Example\nFor example:\ni1.\n**R2** <- R5 + R8 i2.\nR4 <- **R2** + R8\nThe first instruction is calculating a value to be saved in register R2, and the second is going to use this value to compute a result for register R4.\nHowever, in a [pipeline](https://bliptext.com/articles/pipeline-computing), when operands are fetched for the 2nd operation, the results from the first have not yet been saved, and hence a data dependency occurs.\nA data dependency occurs with instruction i2, as it is dependent on the completion of instruction i1.\n\n### Write after read (WAR)\n(i2 tries to write a destination before it is read by i1)\nA write after read (WAR) data hazard represents a problem with concurrent execution.\n\n#### Example\nFor example:\ni1.\nR4 <- R1 + **R5**\ni2.\n**R5** <- R1 + R2\nIn any situation with a chance that i2 may finish before i1 (i.e., with concurrent execution), it must be ensured that the result of register R5 is not stored before i1 has had a chance to fetch the operands.\n\n### Write after write (WAW)\n(i2 tries to write an operand before it is written by i1)\nA write after write (WAW) data hazard may occur in a [concurrent execution](https://bliptext.com/articles/concurrent-computing) environment.\n\n#### Example\nFor example:\ni1.\n**R5** <- R4 + R7 i2.\n**R5** <- R1 + R3\nThe write back (WB) of i2 must be delayed until i1 finishes executing.\n\n## Structural hazards\nA structural hazard occurs when two (or more) instructions that are already in pipeline need the same resource.\nThe result is that instruction must be executed in series rather than parallel for a portion of pipeline.\nStructural hazards are sometimes referred to as resource hazards.\nExample:\nA situation in which multiple instructions are ready to enter the execute instruction phase and there is a single ALU (Arithmetic Logic Unit).\nOne solution to such resource hazard is to increase available resources, such as having multiple ports into main memory and multiple ALU (Arithmetic Logic Unit) units.\n\n## Control hazards (branch hazards or instruction hazards)\nControl hazard occurs when the pipeline makes wrong decisions on branch prediction and therefore brings instructions into the pipeline that must subsequently be discarded.\nThe term branch hazard also refers to a control hazard.\n\n# Eliminating hazards\n\n## Generic\n\n### Pipeline bubbling\nBubbling the pipeline, also termed a pipeline break or pipeline stall, is a method to preclude data, structural, and branch hazards.\nAs instructions are fetched, control logic determines whether a hazard could/will occur.\nIf this is true, then the control logic inserts no operations (NOPs) into the pipeline.\nThus, before the next instruction (which would cause the hazard) executes, the prior one will have had sufficient time to finish and prevent the hazard.\nIf the number of NOPs equals the number of stages in the pipeline, the processor has been cleared of all instructions and can proceed free from hazards.\nAll forms of stalling introduce a delay before the processor can resume execution.\nFlushing the pipeline occurs when a branch instruction jumps to a new memory location, invalidating all prior stages in the pipeline.\nThese prior stages are cleared, allowing the pipeline to continue at the new instruction indicated by the branch.\n\n## Data hazards\nThere are several main solutions and algorithms used to resolve data hazards:\nIn the case of [out-of-order execution](https://bliptext.com/articles/out-of-order-execution), the algorithm used can be:\nThe task of removing data dependencies can be delegated to the compiler, which can fill in an appropriate number of NOP instructions between dependent instructions to ensure correct operation, or re-order instructions where possible.\n\n### Operand forwarding\n\n### Examples\nFor example, 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, i.e.:\ni0: R1 = **6**\ni1: R1 = **3**\ni2: R2 = R1 + **7** = **10**\nFollowing execution, register 2 should contain the value **10**.\nHowever, if i1 (write ****3**** to register 1) does not fully exit the pipeline before i2 starts executing, it means that R1 does not contain the value ****3**** when i2 performs its addition.\nIn such an event, i2 adds **7** to the old value of register 1 (**6**), and so register 2 contains **13** instead, i.e.:\ni0: R1 = **6**\ni2: R2 = R1 + **7** = **13**\ni1: R1 = **3**\nThis error occurs because i2 reads Register 1 before i1 has committed/stored the result of its write operation to Register 1.\nSo when i2 is reading the contents of Register 1, register 1 still contains **6**, not **3**.\nForwarding (described below) helps correct such errors by depending on the fact that the output of i1 (which is ****3****) can be used by subsequent instructions before the value ****3**** is committed to/stored in Register 1.\nForwarding applied to the example means that there is no wait to commit/store the output of i1 in Register 1 (in this example, the output is **3**) before making that output available to the subsequent instruction (in this case, i2). The effect is that i2 uses the correct (the more recent) value of Register 1: the commit/store was made immediately and not pipelined.\nWith forwarding enabled, the Instruction Decode/Execution (ID/EX) stage of the pipeline now has two inputs: the value read from the register specified (in this example, the value **6** from Register 1), and the new value of Register 1 (in this example, this value is **3**) which is sent from the next stage Instruction Execute/Memory Access (EX/MEM).\nAdded control logic is used to determine which input to use.\n\n## Control hazards (branch hazards)\nTo avoid control hazards microarchitectures can:\nIn the event that a branch causes a pipeline bubble after incorrect instructions have entered the pipeline, care must be taken to prevent any of the wrongly-loaded instructions from having any effect on the processor state excluding energy wasted processing them before they were discovered to be loaded incorrectly.\n\n## Other techniques\nMemory latency is another factor that designers must attend to, because the delay could reduce performance.\nDifferent types of memory have different accessing time to the memory.\nThus, by choosing a suitable type of memory, designers can improve the performance of the pipelined data path.\n\n## General","revisionCount":0},"hasMore":false,"nextCursor":null}

History