Every modern CPU issues multiple instructions per cycle. The fundamental architectural question is: who finds the parallelism? In superscalar designs, the hardware does it at runtime. In VLIW (Very Long Instruction Word), the compiler does it at compile time. This single decision cascades into radically different hardware complexity, power budgets, and compiler requirements.

Superscalar: Hardware Scheduling. Your x86 and ARM cores are superscalar. The CPU fetches a stream of sequential instructions, analyzes dependencies between them in real time, and dispatches independent operations to multiple execution units simultaneously. An Apple M4 performance core can issue up to 10 micro-ops per cycle. This requires enormous hardware: dependency tracking logic, reservation stations, register renaming tables, and reorder buffers. The upside is that any compiled binary benefits — old code runs faster on new hardware without recompilation.

VLIW: Compiler Scheduling. A VLIW processor receives a single wide instruction word containing multiple operations that the hardware executes simultaneously with no dependency checking. The compiler is entirely responsible for packing independent operations into each word and inserting NOPs when parallelism isn't available. Intel's Itanium (IA-64) was the most famous VLIW-influenced design, with 128-bit "bundles" containing three operations each. Texas Instruments' C6000 DSPs are a purer example — issuing eight operations per cycle from a single 256-bit fetch packet.

The tradeoffs are stark:

• Hardware complexity: VLIW eliminates the scheduling logic that can consume 20-30% of a superscalar core's transistor budget and power draw. This makes VLIW attractive for embedded DSPs where power matters more than generality.
• Code density: VLIW suffers badly. When the compiler can't find enough parallelism, it inserts NOPs. Itanium binaries were notoriously bloated — often 2-3x larger than equivalent x86 code, thrashing instruction caches.
• Binary compatibility: Superscalar wins decisively. A VLIW binary is locked to a specific number of execution units. Widen the machine from 4-issue to 8-issue? Every binary must be recompiled. Superscalar code just runs faster automatically.
• Compiler burden: VLIW compilers must model the entire pipeline, predict cache behavior, and schedule across branches — problems that are provably hard in the general case. Runtime hardware scheduling handles dynamic conditions (cache misses, branch mispredicts) that no static compiler can fully anticipate.

Rule of thumb: VLIW works well when the workload is predictable and regular (signal processing, media codecs) but struggles with irregular, branch-heavy general-purpose code. This is exactly why VLIW dominates DSPs but lost the server and desktop wars.

Modern designs sometimes blend approaches. ARM's Scalable Vector Extension (SVE) borrows the VLIW idea of exposing parallelism to software, while keeping superscalar hardware scheduling for scalar code. GPU shader compilers also perform VLIW-style packing on some architectures (AMD's older VLIW4/VLIW5 shader engines).