Fallacy: A Deeper Pipeline Always Means Better Performance
It is tempting to assume that adding more pipeline stages always improves performance, since each stage becomes simpler and the clock can run faster. In reality, as discussed earlier when comparing the ARM Cortex-A53 and Intel Core i7, a deeper pipeline increases the branch penalty on a misprediction, discussed earlier regarding control hazards, and increases power consumption, tied to the power wall covered earlier in this series. Pipeline depth is a tradeoff, not a straightforward win.
Fallacy: Pipelining Reduces the Time to Execute a Single Instruction
As emphasized earlier in this series, pipelining improves throughput, not the latency of any individual instruction. A single instruction still takes the same number of stages, and often slightly longer overall, to complete; what changes is how many instructions can be in progress simultaneously.
Fallacy: More Issue Slots Always Translate to Proportional Speedup
As discussed earlier regarding instruction-level parallelism, doubling the number of issue slots does not double real program performance unless the program contains enough independent instructions to fill those slots. Programs dominated by long dependency chains see little benefit from additional issue width, no matter how much hardware is duplicated.
Pitfall: Assuming All Hazards Have the Same Cost
Not every hazard costs the same number of cycles. As covered earlier, most data hazards are resolved by forwarding at no cost at all, while a load-use hazard specifically costs one stall cycle, and a control hazard's cost depends directly on how early in the pipeline the branch outcome can be resolved. Treating all hazards as equally expensive leads to incorrect performance reasoning.
Chapter Summary: From a Simple Datapath to a Modern Superscalar Core
This chapter built a processor from the ground up: starting with basic logic design conventions, constructing a single-cycle datapath and its control logic, then transforming that datapath into a pipelined design to overlap instruction execution. Along the way, this chapter addressed the real complications that overlapping introduces — data hazards resolved through forwarding and stalling, control hazards managed through prediction, and exceptions handled safely without corrupting program state — before finally extending these ideas to instruction-level parallelism and comparing how real commercial processors apply them differently based on their design goals.
Every concept in this chapter exists to answer one central question: how can a fixed set of simple instructions, defined in the previous chapter, be executed as quickly and efficiently as physically possible without producing incorrect results.