You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 54.234.0.0/16 has been blocked (disabled) by ‪JJMC89‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider or colocation provider. To prevent abuse, web hosts and colocation providers may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host or colocation provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a colocation provider's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a colocation web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host or colocation provider (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host or colocation provider.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and requests should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 05:36, 2 January 2025.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪Jon Kolbert‬. The reason given is Open proxy/Webhost: See the help page if you are affected .
- Start of block: 05:40, 21 February 2024
- Expiry of block: 05:40, 21 February 2029
Your current IP address is 54.234.187.160. The blocked range is 54.234.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

You can view and copy the source of this page:

((Short description|Problems with the instruction pipeline in central processing unit (CPU) microarchitectures))
((More citations needed|date=January 2014))
In the domain of [[central processing unit]] (CPU) [[CPU design|design]], '''hazards''' are problems with the [[instruction pipeline]] in CPU [[microarchitecture]]s when the next instruction cannot execute in the following clock cycle,((sfn|Patterson|Hennessy|2009|p=335)) and can potentially lead to incorrect computation results. Three common types of hazards are data hazards, structural hazards, and control hazards (branching hazards).((sfn|Patterson|Hennessy|2009|pp=335-343))

There are several methods used to deal with hazards, including [[pipeline stall]]s/pipeline bubbling, [[#Operand forwarding|operand forwarding]], and in the case of [[out-of-order execution]], the [[scoreboarding]] method and the [[Tomasulo algorithm]].

== Background ==
((further|Instruction pipelining))

[[Instruction (computer science)|Instruction]]s 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. There are many different instruction pipeline [[microarchitecture]]s, and instructions may be [[out-of-order execution|executed out-of-order]]. A hazard occurs when two or more of these simultaneous (possibly out of order) instructions conflict.

==Types==

===Data hazards===
Data hazards occur when instructions that exhibit [[data dependence]] modify data in different stages of a pipeline. Ignoring potential data hazards can result in [[race condition]]s (also termed race hazards). There are three situations in which a data hazard can occur:

# read after write (RAW), a ''true dependency''
# write after read (WAR), an ''anti-dependency''
# write after write (WAW), an ''output dependency''
Read after read (RAR) is not a hazard case.

Consider two instructions ((Mono|i1)) and ((Mono|i2)), with ((Mono|i1)) occurring before ((Mono|i2)) in program order.

====Read after write (RAW)====
(((Mono|i2)) tries to read a source before ((Mono|i1)) writes to it)
A 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. This can occur because even though an instruction is executed after a prior instruction, the prior instruction has been processed only partly through the pipeline.

=====Example=====
For example:

 i1. '''R2''' <- R5 + R8
 i2. R4 <- '''R2''' + R8

The first instruction is calculating a value to be saved in register ((Mono|R2)), and the second is going to use this value to compute a result for register ((Mono|R4)). However, in a [[Pipeline (computing)|pipeline]], when operands are fetched for the 2nd operation, the results from the first have not yet been saved, and hence a data dependency occurs.

A data dependency occurs with instruction ((Mono|i2)), as it is dependent on the completion of instruction ((Mono|i1)).

====Write after read (WAR)====
(((Mono|i2)) tries to write a destination before it is read by ((Mono|i1)))
A write after read (WAR) data hazard represents a problem with concurrent execution.

=====Example=====
For example:

 i1. R4 <- R1 + '''R5'''
 i2. '''R5''' <- R1 + R2

In any situation with a chance that ((Mono|i2)) may finish before ((Mono|i1)) (i.e., with concurrent execution), it must be ensured that the result of register ((Mono|R5)) is not stored before ((Mono|i1)) has had a chance to fetch the operands.

====Write after write (WAW)====
(((Mono|i2)) tries to write an operand before it is written by ((Mono|i1)))
A write after write (WAW) data hazard may occur in a [[Concurrent computing|concurrent execution]] environment.

=====Example=====
For example:

 i1. '''R5''' <- R4 + R7
 i2. '''R5''' <- R1 + R3

The write back (WB) of ((Mono|i2)) must be delayed until ((Mono|i1)) finishes executing.

===Structural hazards===
A structural hazard occurs when two (or more) instructions that are already in pipeline need the same resource. The result is that instruction must be executed in series rather than parallel for a portion of pipeline. Structural hazards are sometimes referred to as resource hazards.

Example:
A situation in which multiple instructions are ready to enter the execute instruction phase and there is a single ALU (Arithmetic Logic Unit). One 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.

===Control hazards (branch hazards or instruction hazards)===
Control hazard occurs when the pipeline makes wrong decisions on branch prediction and therefore brings instructions into the pipeline that must subsequently be discarded. The term branch hazard also refers to a control hazard.

==Eliminating hazards==

===Generic===

==== ((Anchor|PIPELINE-FLUSH))Pipeline bubbling ====
((Main|Bubble (computing)))

''Bubbling the pipeline'', also termed a ''pipeline break'' or ''pipeline stall'', is a method to preclude data, structural, and branch hazards. As instructions are fetched, control logic determines whether a hazard could/will occur. If this is true, then the control logic inserts ((Mono|no operation))s (((Mono|[[NOP (code)|NOP]]))s) into the pipeline. Thus, before the next instruction (which would cause the hazard) executes, the prior one will have had sufficient time to finish and prevent the hazard. If the number of ((Mono|NOP))s equals the number of stages in the pipeline, the processor has been cleared of all instructions and can proceed free from hazards. All forms of stalling introduce a delay before the processor can resume execution.

''Flushing the pipeline'' occurs when a branch instruction jumps to a new memory location, invalidating all prior stages in the pipeline.  These prior stages are cleared, allowing the pipeline to continue at the new instruction indicated by the branch.<ref>((cite web
 | url = http://www.cs.iastate.edu/~prabhu/Tutorial/PIPELINE/branchPred.html
 | title = Branch Prediction Schemes
 | date = 2001-04-06 | access-date = 2014-07-19
 | website = cs.iastate.edu
))</ref><ref>((cite web
 | url = http://classes.soe.ucsc.edu/cmpe110/Winter04/pipelining.txt
 | title = Data and Control Hazards
 | date = 2004-02-23 | access-date = 2014-07-19
 | website = classes.soe.ucsc.edu
))</ref>

===Data hazards===
There are several main solutions and algorithms used to resolve data hazards:
* insert a ''pipeline bubble'' whenever a read after write (RAW) dependency is encountered, guaranteed to increase latency, or
* use [[out-of-order execution]] to potentially prevent the need for pipeline bubbles
* use ''[[operand forwarding]]'' to use data from later stages in the pipeline

In the case of [[out-of-order execution]], the algorithm used can be:

* [[scoreboarding]], in which case a ''pipeline bubble'' is needed only when there is no functional unit available
* the [[Tomasulo algorithm]], which uses [[register renaming]], allowing continual issuing of instructions

The task of removing data dependencies can be delegated to the compiler, which can fill in an appropriate number of ((Mono|NOP)) instructions between dependent instructions to ensure correct operation, or re-order instructions where possible.

====((Anchor|OPERAND-FORWARDING))Operand forwarding====
((Main|Operand forwarding))

====Examples====
: ''In the following examples, computed values are in '''bold''', while Register numbers are not.''

For 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.:

 i0: R1 = '''6'''
 i1: R1 = '''3'''
 i2: R2 = R1 + '''7''' = '''10'''

Following execution, register 2 should contain the value '''10'''. However, 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. In such an event, i2 adds '''7''' to the old value of register 1 ('''6'''), and so register 2 contains '''13''' instead, i.e.:

 i0: R1 = '''6'''
 i2: R2 = R1 + '''7''' = '''13'''
 i1: R1 = '''3'''

This error occurs because i2 reads Register 1 before i1 has committed/stored the result of its write operation to Register 1. So when i2 is reading the contents of Register 1, register 1 still contains '''6''', ''not'' '''3'''.

Forwarding (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.

Forwarding 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.

With 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). Added control logic is used to determine which input to use.

===Control hazards (branch hazards)===
To avoid control hazards microarchitectures can:

* insert a ''pipeline bubble'' (discussed above), guaranteed to increase [[Latency (engineering)|latency]], or
* use [[branch prediction]] and essentially make educated guesses about which instructions to insert, in which case a ''pipeline bubble'' will only be needed in the case of an incorrect prediction

In 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.

=== Other techniques ===
Memory latency is another factor that designers must attend to, because the delay could reduce performance. Different types of memory have different accessing time to the memory. Thus, by choosing a suitable type of memory, designers can improve the performance of the pipelined data path.<ref>((cite journal|title=Design Example of Useful Memory Latency for Developing a Hazard Preventive Pipeline High-Performance Embedded-Microprocessor |journal=VLSI Design |volume=2013 |pages=1–10 |date=2012-12-27 |doi=10.1155/2013/425105 |last1=Cheng |first1=Ching-Hwa |doi-access=free ))</ref>

==See also==
((Div col|colwidth=25em))
* [[Feed forward (control)]]
* [[Register renaming]]
* [[Data dependency]]
* [[Control dependency]]
* [[Hazard (logic)]]
* [[Hazard pointer]]
* ((Section link|Classic RISC pipeline|Hazards))
* [[Speculative execution]]
* [[Branch delay slot]]
* [[Branch predication]]
* [[Branch predictor]]
* [[Race condition]]
((div col end))

==References==
((reflist))

===General===
((refbegin))
* ((cite book|last1=Patterson|first1=David|author-link1=David Patterson (scientist)|last2=Hennessy|first2=John|author-link2=John L. Hennessy|title=Computer Organization and Design|year=2009|edition=4th|publisher=[[Morgan Kaufmann]]|isbn=978-0-12-374493-7))
* ((cite book|last1=Patterson|first1=David |last2=Hennessy|first2=John |title=Computer Architecture: A Quantitative Approach|year=2011|edition=5th|publisher=[[Morgan Kaufmann]]|isbn=978-0-12-383872-8))
* ((cite book |first=John P. |last=Shen |first2=Mikko H. |last2=Lipasti |chapter=2.2.3.2 Identication of Pipeline Hazards |title=Modern Processor Design: Fundamentals of Superscalar Processors |orig-year=2004 |year=2013 |isbn=9781478610762 |chapter-url=https://books.google.com/books?id=ffQqAAAAQBAJ&pg=PA73 |pages=73–78))
((refend))

== External links ==
* ((cite web |url=http://users.ece.cmu.edu/~jhoe/distribution/2010/date10.pdf |title=Automatic Pipelining from Transactional Datapath Specifications |access-date=23 July 2014))
* ((cite web |url=http://cseweb.ucsd.edu/classes/wi05/cse240a/pipe2.pdf |title=Pipeline hazards |date=18 January 2005 |first=Dean |last=Tulsen))

((CPU technologies|state=collapsed))

((DEFAULTSORT:Hazard (Computer Architecture)))
[[Category:Instruction processing]]

Pages transcluded onto the current version of this page (help):

Hazard (computer architecture) (edit)
Template:Ambox (view source) (template editor protected)
Template:Anchor (view source) (template editor protected)
Template:CPU technologies (edit)
Template:Cite book (view source) (protected)
Template:Cite journal (view source) (protected)
Template:Cite web (view source) (protected)
Template:Div col (view source) (template editor protected)
Template:Div col/styles.css (view source) (template editor protected)
Template:Div col end (view source) (template editor protected)
Template:Find sources mainspace (view source) (template editor protected)
Template:Further (view source) (template editor protected)
Template:Hlist/styles.css (view source) (protected)
Template:Ifsubst (view source) (template editor protected)
Template:Main (view source) (template editor protected)
Template:Main other (view source) (protected)
Template:Mono (view source) (template editor protected)
Template:Mono/styles.css (view source) (template editor protected)
Template:More citations needed (view source) (template editor protected)
Template:Navbox (view source) (template editor protected)
Template:Pagetype (view source) (protected)
Template:Processor technologies (edit)
Template:Refbegin (view source) (template editor protected)
Template:Refbegin/styles.css (view source) (template editor protected)
Template:Refend (view source) (template editor protected)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:SDcat (view source) (protected)
Template:Section link (view source) (template editor protected)
Template:Sfn (view source) (template editor protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Module:Anchor (view source) (template editor protected)
Module:Arguments (view source) (protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:Find sources (view source) (template editor protected)
Module:Find sources/config (view source) (template editor protected)
Module:Find sources/links (view source) (template editor protected)
Module:Find sources/templates/Find sources mainspace (view source) (template editor protected)
Module:Footnotes (view source) (template editor protected)
Module:Footnotes/anchor id list (view source) (template editor protected)
Module:Footnotes/anchor id list/data (view source) (template editor protected)
Module:Footnotes/whitelist (view source) (template editor protected)
Module:Format link (view source) (template editor protected)
Module:Hatnote (view source) (template editor protected)
Module:Hatnote/styles.css (view source) (template editor protected)
Module:Hatnote list (view source) (template editor protected)
Module:Labelled list hatnote (view source) (template editor protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Navbar (view source) (protected)
Module:Navbar/configuration (view source) (protected)
Module:Navbar/styles.css (view source) (protected)
Module:Navbox (view source) (template editor protected)
Module:Navbox/configuration (view source) (template editor protected)
Module:Navbox/styles.css (view source) (template editor protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:SDcat (view source) (protected)
Module:Section link (view source) (template editor protected)
Module:String (view source) (protected)
Module:TableTools (view source) (protected)
Module:Unsubst (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Hazard (computer architecture).

Retrieved from "https://en.wikipedia.org/wiki/Hazard_(computer_architecture)"