Pipelining Hazards in 8086

Photo by Antonin Duallia on Unsplash

What is Pipelining ?

Unlike the picture above which shows an ducting pipeline today we are going to discuss about the instruction pipeline in 8086 microcontroller. The formal definition of instruction pipeline goes something like this

Pipelining is the process of arrangement of hardware elements of CPU such that the overall performance is increased.

Basics

Pipelining is a process of gathering instructions from the processor through a pipeline. This method has several advantages like storing and executing instructions in a systematic manner. You might come across other content out there which talks about pipeline processing, that’s another name for pipelining. Now pipelining is a technique which allows the microcontroller to run multiple instructions at the same time.

This does sound too good to be true, doesn’t it? Well it kind of is, because when there are so many features there tend to be some hazards that creep their way along. Fortunately for us, there are plenty of ways of dealing with these hazards, which we are going to discuss further on this blog.

Now before moving to the actual hazards in pipelining if you are new to the complete pipelining process we highly recommend to watch this video before moving any further.

Hazards in Pipelining

Now assuming you know the basics of pipelining lets talk about the hazards in pipelining, their causes, types and how to solve them.

Why are hazards caused ?

There is a lot going on in a pipeline. One instruction is in the fetch state one in decode and another in operand state. There is bound to be something which has to go wrong if the instructions are not managed well. Many different combinations of instructions could result in unanticipated hazards. It becomes quite a cumbersome task to resolve these hazards as the complexity and depth of the pipeline increase.

Lets take an example for better understanding. Lets say you and you friend are standing on two extremes of a building. Both of you create the pipeline. Now the pattern is you call the name of your friend, after he listens his name he shouts out your name, and the process continues. Now a person living on the middle floor shouts at the same time your friend shouts (this can be another instruction further down the pipeline) so you just hear “SHUT UP!” but not your name, now both you and your friend are trying to listen to your respective names but nothing is happening and the guy on the middle floor is happy, this is a hazard in the pipelining

So the formal definition of a pipelining hazards can be given as

A situation where the instruction cannot proceed through the pipeline as it should is known as a hazard in the pipeline.

Types of Hazards

There are mainly 3 types of hazards bugging the computer engineers for years now

1. Data Hazards
2. Branch Hazards
3. Structural Hazards

Data Hazards

Photo by Luke Chesser on Unsplash

The above example illustrates a data hazard. The hazards that arise most commonly in pipeline processors are data hazards. Forwarding and stalling are viable options for resolving these issues. However, as the number of instructions grows, the difficulty of detecting risks grows dramatically. Many different combinations of instructions could result in unanticipated hazards in this situation. To ensure that all danger combinations are considered, completeness detection of data hazards is required. A data hazard can develop in one of three circumstances:

1. Read After Write (RAW) — True Dependency
   A RAW data hazard occurs when an instruction refers to a computed or retrieved result that has not yet been calculated or retrieved. This can happen because the previous instruction has only been processed partially through the pipeline.
2. Write After Read (WAR) — Anti-Dependency
   A data hazard caused by write after read (WAR) indicates a difficulty with concurrent execution.
3. Write After Write (WAW) — Output Dependency
   In a concurrent execution environment, a write after write (WAW) data hazard might occur.

Branch Hazards

Photo by Sebastian Herrmann on Unsplash

Branch Hazards are also known as control hazards. Control hazard occurs when the pipeline makes inaccurate branch prediction decisions, resulting in instructions that must be discarded entering the pipeline.

Structural Hazards

Photo by Ricardo Gomez Angel on Unsplash

When two (or more) instructions in the pipeline require the same resource, a structural hazard occurs. As a result, for a portion of the pipeline, instructions must be performed in series rather than parallel. Occasionally, structural dangers are referred to as resource hazards.

Handling Hazards

Now as these problems have been around forever we have developed solutions to these some of these hazards, which we will be discussing below

Handling Data Hazards

1. Forwarding : It modifies the pipeline with specific circuitry. This method works because the required values take less time to go via a wire than a pipeline segment does to compute its result.
2. Code Reordering : To reorganize code, we’ll need specialized software. This type of software is known as a hardware-dependent compiler.
3. Stall Insertion : A stall is a cycle in the pipeline without new input. It adds one or more install (no-op instructions) to the pipeline, delaying execution of the present instruction until the required operand is written to the register file; however, this strategy reduces pipeline efficiency and throughput.

Handling Branch Hazards

1. Freeze / Flush : The simplest way to deal with branches is to freeze or flush the pipeline, holding or removing all instructions that follow the branch until the destination is determined
2. Not Taken Method : Treating every branch as not taken, and simply allowing the hardware to proceed as if the branch had not been executed, is a higher-performance and just slightly more complex technique. The intricacy of this method stems from the need to understand when an instruction might affect the state and how to “back out” such a change.
3. Already Taken Method : Another option is to consider each branch as if it were already taken. We assume the branch is taken and begin fetching and executing at the target address as soon as the branch is decoded and the target address is computed.
4. Branch Prediction : We can use branch prediction to make reasonable predictions about which instructions to insert, and a pipeline bubble will only be required if the forecast is erroneous.

Handling Structural Hazards

1. Stall Insertion : As mentioned earlier the most effective way to get rid of structural hazards is to insert a stall cycle or pipelining bubble
2. Pipelining of resources : Usage of separate cache memory, dividing reading from and writing to register into the clock cycle, etc.

Conclusion

The usage of instruction pipelining completely revolutionized the microcontroller world, but it came with its dangers or hazards. After applying various logics for theses problems some solid solutions have been developed to remove theses hazards from the pipeline and as a computer scientist you must know their meaning, causes and solutions which were discussed in this blog.

Find my writings interesting you can find my other articles here.