A scalar pipeline fetches, decodes, and issues one instruction per cycle. A superscalar pipeline does several in parallel — typical desktop CPUs are 4-wide to 8-wide. The width is set by how many instructions the front-end can decode, how many can be dispatched into the reservation stations, and how many functional units can accept work in the same cycle. The tightest of those three is the real issue width.

The hard part isn't building more ALUs — it's the dispatch crossbar. To issue N instructions in a cycle, the scheduler must check N instructions against every reservation station entry, find N ready instructions, and route them to N functional units without conflicts. The dependency-check logic scales as O(N²): every instruction in the issue window must compare its source registers against every other in-flight destination. That's why going from 4-wide to 8-wide roughly quadruples the wakeup/select logic area and power, but only doubles peak throughput.

Concrete example: Apple's M1 Firestorm core. It decodes 8 instructions per cycle and can dispatch up to ~8 µops into a 630-entry reorder buffer. To make that work, Apple spent transistor budget on a massive 354-entry integer physical register file and parallel decoders that can each handle the fixed-length ARM64 instruction independently (no length-decoding serialization like x86 needs). Intel's contemporary Golden Cove was only 6-wide partly because variable-length x86 decoding forces a serial pre-decode step that limits parallelism — they need a µop cache to bypass it on hot paths.

The dependency wall. Average integer code has roughly 1.5–2 independent instructions per cycle available before you start tracking branches and memory aliasing. To extract more, you need aggressive branch prediction (covered earlier), register renaming, and a large reorder buffer to look further ahead. Doubling issue width from 4 to 8 typically yields only ~30% more IPC on real workloads — the rest is wasted slots.

Rule of thumb: useful sustained IPC ≈ √(issue_width × ROB_size / 30). For a 4-wide core with a 128-entry ROB, that's about 2.6 IPC sustained. For an 8-wide core with a 600-entry ROB, about 4.0 IPC. You can see why Apple paired wide issue with a huge ROB — narrow window kills wide issue.

The other limit is the issue port assignment. Most cores have asymmetric ports — e.g., only two ports can do loads, only one can do divides. Compilers and schedulers must spread instruction types to avoid port pressure, which is why microbenchmarks that hammer one operation type rarely hit peak issue width.