VLIW
/ V-L-I-W, "vee-liw" /
A superscalar core figures out at run time, in hardware, which instructions can go together — like a maître d' deciding on the fly which orders to send to which cook. VLIW (very long instruction word) takes the opposite approach: it makes the compiler decide ahead of time, before the program ever runs, and bake the decision into the instructions themselves. The 'very long' word is one fat instruction that already names several operations to be done in parallel.
Concretely, a VLIW machine has several execution slots — say, two integer units, one memory unit, one branch unit. The compiler analyzes the program, finds independent operations, and packs them into one long instruction word with one operation per slot, padding empty slots with no-ops when it cannot find enough parallel work. The hardware then simply issues every slot in lockstep, no dependence-checking logic required. This shifts the hard scheduling work from expensive run-time hardware to free compile-time software — the appeal is a simpler, lower-power, potentially wider machine.
The honest catch is why VLIW never displaced superscalar for general-purpose CPUs. The compiler must guess things it cannot fully know in advance — especially memory latencies (a load might hit or miss the cache) and which way branches go — so its static schedule is often pessimistic, and code compiled for one width does not run optimally on another (poor binary compatibility). Intel's Itanium (EPIC, a VLIW relative) is the famous cautionary tale. VLIW thrives instead in domains where the dataflow is regular and predictable — digital signal processors (DSPs) and some GPUs and AI accelerators — where the compiler really can see the whole schedule.
One VLIW word might encode: slot0 = add x3,x1,x2; slot1 = mul x6,x4,x5; slot2 = load x7,[x8]; slot3 = nop. All three real operations fire together this cycle because the compiler proved they are independent.
The compiler, not the hardware, packs parallel operations into one wide instruction.
VLIW is not simply 'superscalar done in software and therefore better'. Static scheduling cannot react to run-time surprises like cache misses, which is why general-purpose CPUs kept dynamic, out-of-order hardware instead.