LogoفارسیFA

Data Hazards in Pipelines: Forwarding Versus Stalling

Overlapping instruction execution creates a serious problem when one instruction needs a result that a previous instruction has not finished computing yet. This article explains what data hazards are, how forwarding solves most of them without losing any performance, and why some situations still require the pipeline to stall.

Data HazardsForwardingPipeline Stalling

~3 min read · Updated Sep 6, 2026

What a Data Hazard Is

In a pipelined processor, several instructions are in progress simultaneously. A Data Hazard occurs when an instruction needs to use a value that a preceding instruction, still moving through the pipeline, has not yet finished computing and written back to the register file.

Consider this sequence of instructions:

add a, b, c
sub d, a, e

The second instruction needs the value of a, but the first instruction has not yet reached its write-back stage by the time the second instruction reaches decode. Without any correction, the second instruction would read a stale, outdated value of a from the register file.

The First Solution: Forwarding

Forwarding (also called Bypassing) solves this without losing any clock cycles, by adding extra wiring that routes a result directly from where it is computed to where it is needed, skipping the normal path through the register file entirely.

Without forwarding:
add computes result → written to register file (cycle 5)
sub needs result → read from register file (cycle 3) — too early, wrong value

With forwarding:
add computes result in EX stage (cycle 3)
result is forwarded directly into sub's EX stage (cycle 4)

Because the result the second instruction needs is available right after the first instruction's execute stage, extra hardware paths can feed that value forward in time to reach the second instruction exactly when it needs it, avoiding any wasted cycles.

When Forwarding Alone Is Not Enough

Forwarding solves most data hazards, but not all of them. A Load-Use Hazard occurs specifically when an instruction immediately following a load needs the value that load is retrieving:

ld a, 0(b)
add d, a, e

The loaded value is not available until the end of the memory access stage, which happens later than the point where the following instruction's execute stage needs it, even with forwarding wiring in place. In this specific case, forwarding cannot deliver the value in time.

The Second Solution: Stalling

When forwarding cannot resolve a hazard in time, the pipeline must insert a Stall (also called a Bubble): the dependent instruction, and everything behind it, is held in place for one clock cycle while the needed value becomes available, at the cost of one cycle of lost throughput.

ld a, 0(b)      : IF ID EX MEM WB
[bubble inserted]
add d, a, e     : IF ID  --  EX MEM WB

This deliberately wastes one cycle rather than producing an incorrect result, which is always the correct tradeoff, since accuracy cannot be sacrificed for speed.

Why This Distinction Matters for Compiler Design

Because load-use stalls specifically cost a cycle, compilers that understand this hazard can sometimes reorder independent instructions to be placed immediately after a load, filling what would otherwise be a wasted stall cycle with useful work instead — a technique called Instruction Scheduling, which relies directly on understanding this hazard's exact cause.

Written & researched by Dr. Shahin Siami

Related Articles

Cache Fundamentals: How Small, Fast Memory Predicts What You Need Next

A cache works because programs tend to access the same or nearby data repeatedly rather than randomly. This article explains the principle of locality that makes caching effective, how a direct-mapped cache locates data using an address, and what happens on a cache hit versus a cache miss.

Continue

The Memory Hierarchy: Why Computers Use Several Kinds of Memory

No single memory technology is simultaneously fast, large, and cheap. This article introduces the concept of a memory hierarchy that combines several different memory technologies to approximate the speed of the fastest one at the cost of the cheapest, then walks through the core technologies that make up each level.

Continue

Common Misconceptions About Processor Design and Chapter Four's Big Picture

After covering datapaths, pipelining, hazards, and real-world processor comparisons, it is time to correct a handful of persistent misconceptions about how processors actually behave. This article addresses common fallacies about pipelining and performance, then ties together the full journey from simple datapaths to superscalar execution covered throughout this chapter.

Continue

Real-World Pipelines: Comparing ARM and Intel, and Speeding Up Matrix Multiply

Theoretical pipeline concepts take concrete shape in real commercial processors, which vary widely in pipeline depth and issue width depending on their design goals. This article compares how the ARM Cortex-A53 and Intel Core i7 implement pipelining differently for power efficiency versus raw performance, then shows how instruction-level parallelism accelerates matrix multiplication in practice.

Continue

Instruction-Level Parallelism: Executing More Than One Instruction at Once

A single pipeline can only advance one instruction into each stage per cycle, which caps its performance at roughly one instruction per clock. This article explains how processors go beyond that limit by issuing multiple instructions simultaneously, the hardware duplication this requires, and the fundamental limits imposed by dependencies between instructions.

Continue

How a Pipelined Processor Handles Exceptions

Not every instruction executes as expected — some trigger error conditions like an undefined opcode or an arithmetic overflow that the processor must respond to safely. This article explains what exceptions are, how a pipelined processor detects and handles them without corrupting program state, and why exceptions are treated similarly to control hazards.

Continue
Previous ArticleNext Article