a pipeline stall

On the assembly line, sometimes the only honest move is to pause: the part the next station needs simply is not ready, so you hold the unfinished work where it is and wait a beat. A pipeline stall is exactly that — the hardware freezes one or more instructions in place for a cycle (or several) because letting them go forward would read a wrong value or grab a busy resource. It is the universal, brute-force cure that works for any hazard when nothing cleverer applies.

Mechanically, a stall freezes the front of the pipeline. The instructions in the stalled stage and earlier do not advance — the program counter and the early pipeline registers hold their contents instead of loading new ones — while the instructions already past the stall point flow on normally. Into the gap that opens behind them, the hardware injects a do-nothing instruction, a bubble, so the later stages have something harmless to process. The circuitry that detects the hazard and applies the freeze is called an interlock: a hazard-detection unit notices, for example, a load-use conflict and signals the pipeline to stall exactly one cycle.

Stalls are correct but costly: every stalled cycle is a cycle in which no useful instruction finishes, so stalls directly raise the effective cycles-per-instruction above the ideal of one. That is why architects work so hard to avoid them — forwarding to dodge data hazards, extra hardware to dodge structural ones, prediction to dodge control ones. A stall is the fallback you reach for only when those cannot help, most famously the one unavoidable stall of the load-use hazard. Good code and good compilers fill stall slots with independent work so the freeze costs nothing.