The compiler takes the wheel: what a VLIW is

One long word, one slot per unit

Your first architecture course built a pipeline that issues one instruction per cycle. Lesson 8 widened it: a superscalar issues several per cycle, and its hardware decides at run time which ones may go together. A VLIW issues several per cycle too, but the decision was taken earlier, by the compiler, and written into the program.

The notes sum the idea up in one highlighted line: "VLIW architectures represent a shift of complexity from the hardware to the compiler" (p. 267). A statically scheduled processor trusts "the compiler to 'fill the pipeline' and avoid hazards at compile time" (p. 266).

The operations inside a bundle are also called "syllables" (p. 267). A 4-issue VLIW has four slots per bundle, a 5-issue one five. The 2024 and 2026 papers use a 3-issue machine, June 2025 a 4-issue one with a second memory unit, and the sentence that describes the machine comes back almost word for word in all three.

Put a loop on that machine: the first loop of the 22 June 2026 paper.

LOOP1: LD    F2, 0(R1)      ; I0
       FADD  F6, F2, F2     ; I1
       SD    F6, 0(R1)      ; I2
       ADDUI R1, R1, 4      ; I3
       BNE   R1, R3, LOOP1  ; I4

The compiler fills a timetable with one row per clock cycle and one column per unit. The LD goes in C1. The FADD needs F2, which the memory unit delivers 3 cycles later: C4. The SD needs F6, ready 3 cycles after the FADD: C7. The ADDUI overwrites R1, which the SD still has to read; since the register file allows a read and a write of the same register in one cycle, the ADDUI may share C7 with the SD. The BNE needs the new R1, and an integer result reaches a branch 2 cycles later: C9. C10 is the delay slot.

Ten bundles of three slots: 30 slots, 5 operations, 25 empty. In the exam you leave the empty cells blank — the papers say "Please do not write in NOPs" — but in the program each one is a NOP, an operation that does nothing and still occupies its slot of the word (p. 266). The example formula sheet on the course page, prepared by a student, measures the waste in one line:

The papers ask three more numbers about the same table, all treated in lesson 20: the critical path, by the papers' convention the 10 cycles of the iteration with its delay slot; the CPI, cycles over instructions, 10 / 5 = 2; and the FP operations per cycle, 1 / 10 = 0.1.

Fig. 1 zooms into one row, bundle C7. Three rules keep such a word cheap for the hardware (pp. 267, 269). There is a single program counter, and each fetch brings one whole bundle. A bundle holds at most one branch, so each cycle has one next-PC decision to make. And each slot is wired to its own unit, so the decoder routes nothing.

A bundle is one row of the compiler's timetable: one slot per functional unit, an operation or a NOP in each, fetched by a single program counter.

Who handles each hazard

"The key difference compared to traditional superscalar processors lies in who decides what can run in parallel" (p. 266). A superscalar's hardware analyses dependences while the program runs; in a VLIW "this analysis is performed entirely at compile time" (p. 266). The compiler's job list on the same page has four lines: identify independent operations, solve structural hazards, solve data hazards, insert NOPs where nothing fits. Table 2 sets the two answers side by side.

The RAW row is where the compiler earns its keep. The notes' example: if C = A * B takes two cycles, "the compiler may schedule a NOP after it, before allowing an instruction that depends on C to execute" — or an independent instruction that has to run anyway (p. 270). A pipelined unit does not change the rule. The papers' FP ALU is fully pipelined: it accepts a new FADD every cycle, yet each FADD's result appears 3 cycles after it issues.

Name dependences cost less: a WAR or a WAW shares a register name but carries no value (lesson 7). The compiler resolves them by "appropriately choosing the timing of operations" or by "using register renaming techniques" (p. 270), that is, by writing the result into another register. Structural hazards disappear "through scheduling decisions" (p. 270): with one memory slot, two memory operations simply never share a bundle.

So nothing on the chip checks the schedule. A schedule that ignores a latency does not run slower: it computes a wrong value. That is the meaning of "This static management of hazards is crucial because the hardware in VLIW processors does not dynamically detect or resolve data hazards during execution" (p. 270) — and the answer to the first question of the puzzle: the TRACE did not check its 28 operations because its compiler already had.

In a VLIW the compiler resolves RAW, WAR, WAW and structural hazards with latencies it knows in advance; the hardware only stalls on what nobody can foresee, a cache miss, and flushes a mispredicted branch.

The hardware that stays

Moving the scheduler into the compiler removes the scoreboard, the reservation stations and the dependence checks — "no complex dynamic scheduling (like Tomasulo or Scoreboarding)" (p. 275). It does not remove everything. Fig. 2 redraws the VLIW datapath of the notes (p. 268).

It is the five-stage pipeline of your first course, widened, with a stage of its own for the register read and the data-cache access inside EX: Instruction Fetch, Instruction Decode, Register Read, Execution and Write Back (p. 268). IF fetches one bundle; ID splits it into its operations; from then on "each operation within a bundle proceeds independently through the functional units connected to the pipeline" (p. 268).

The register file is what the notes call "one of the non-trivial aspects of the hardware design" (p. 268). An operation reads up to two registers and writes one, and all the operations of a bundle do it in the same cycle: a 4-issue VLIW needs a register file able to "read eight source operands and write four destination results every clock cycle" (p. 268). This is the shared, multi-ported register file.

As background from the textbooks, not from the notes: every port adds its own access lines to every cell of the register file, so its area and power grow roughly with the square of the number of ports. That is the bill behind the clustered VLIWs of section 4.

Decoding stays trivial when there is one unit per slot: "each operation is directed straight to its corresponding functional unit for execution without the need for complex arbitration" (p. 269). With more units than slots, the machine needs a dispatch network — the crossbars of Fig. 2 — that forwards each operation, with its operands, to a free unit of the right kind (p. 269).

Two run-time events escape the compiler (p. 272). Whether a load misses in the data cache depends on the run: "If a cache miss occurs, the processor experiences a stall, which was not anticipated during static scheduling" — the whole timetable freezes until the data arrives. And a static branch hint can be wrong: the hardware must detect the misprediction and flush the bundles fetched behind it (pp. 271–272). Even a VLIW keeps an interlock for misses and flush logic for branches.

Gone: the hardware that finds parallelism. Kept: the pipeline, a register file with 2k read and k write ports, a dispatch network when units outnumber slots, a stall on a data-cache miss and a flush on a misprediction.

Every result needs a name: register pressure

Take the notes' example (p. 271). A bundle carries two FP operations of five cycles each; their destination registers "remain occupied for the entire duration of those five cycles". A new bundle issues every cycle, so by the time the first two results are written, five bundles have issued: 2 × 5 = 10 registers are reserved for results that do not exist yet. Put such operations in all four slots and you reach the notes' "up to twenty operations competing for register resources".

It is the count of people in a queue: arrivals per minute times minutes each one stays. This pressure on the register file is what the notes call register pressure.

Predict: every cycle, a 4-issue bundle starts one load (latency 3), two FP operations (latency 5) and one integer operation (latency 1). How many registers do results in flight hold?

Renaming makes it worse (p. 271). To remove a WAR or a WAW, the compiler writes the later result into a different register: it "avoids conflicts" but "increases the number of physical register needed". In a VLIW those are the architectural registers, the F0 … F31 the instruction set names; there is no hidden pool behind them. Lesson 15 did exactly this to an unrolled loop: the two registers each copy writes became eight.

Compare Tomasulo. There the code keeps naming F2 and F4, and the hardware renames every result into a reservation-station tag that no program ever sees. The values in flight still need storage — but it is silicon, bought once with the chip, not names taken from the fixed budget of the instruction set.

When the names run out, the compiler has the two ways out the widget shows (p. 271): "careful allocation strategies" — fewer operations in flight and a longer schedule — or "spilling values temporarily to memory": a store now and a reload later, both in memory slots, which pays only for a value that waits longer than the reload takes. The open challenges of the notes add a hardware remedy: clustered VLIW designs, several smaller register files, each serving a subset of the units (p. 274).

Static scheduling moves the cost of renaming from hardware tags to architectural registers: every result in flight needs a name the instruction set provides.

As fast as possible, without changing the answer

Code scheduling is "the process of rearranging program instructions to maximize parallelism during execution" (p. 275). Its goal is to reorder the instructions statically so that the execution time is minimised and semantic correctness is preserved: "we want the program to run as fast as possible without changing what it computes" (p. 275). On a VLIW nobody downstream reorders anything. If the compiler schedules badly, "the result is many NOPs and a waste of hardware resources" (p. 275).

Semantic correctness has a precise meaning (p. 275): every RAW is respected — a read comes after the write it depends on — and no WAR or WAW is violated; the scheduler analyses the dependence graph, reorders only when it is safe, and renames to remove false dependences. Try three tempting moves on LOOP1.

The second move would even pay: with the ADDUI in C1 and the SD rewritten as SD F6, -4(R1), the BNE could close the iteration in C7 and LOOP1 would take 8 cycles instead of 10. The papers rule this out in so many words — "do NOT introduce any software pipelining, loop unrolling and modifications to loop indexes" — so in the exam you reorder, you do not rewrite.

Such a scheduler works on a basic block, "a straight-line code sequence without branches except at the entry and exit points" (p. 273). Basic blocks are short — "for typical programs, only around 4 to 7 instructions are found between branches" (p. 273) — and the RAW chains inside them limit the parallelism further. LOOP1 is a five-instruction block whose chain LD → FADD → SD leaves 25 of its 30 slots empty. Filling them needs techniques that look beyond one block: unrolling, software pipelining and trace scheduling, the subject of lesson 21.

A correct schedule keeps every RAW and lets no write overtake a read (WAR) or another write (WAW) of the same register; within those rules, the shortest one wins.

What you buy, what you pay — and the answer to the puzzle

The notes list three advantages (p. 273). A VLIW exploits ILP statically, with high performance "even without the complex runtime scheduling hardware used in superscalar designs". The compiler analyses the program "with a much larger instruction window than would be feasible in hardware" — a whole loop, a whole function — especially after unrolling or software pipelining. And less hardware means "smaller die areas", "cheaper production costs and lower power consumption, making VLIWs attractive for embedded applications"; the fixed format simplifies decoding, and adding a unit means adding a slot.

Against them stand four open challenges (pp. 273–274). The machine needs strong compiler technology, inside basic blocks and across them. Code grows, with fixed bundles and NOPs, and compression "add[s] extra decoding complexity". Register management suffers from renaming, which clustered designs only partly fix. And the fourth is "a major limitation", binary incompatibility: "Even small changes in the number of slots, the types of functional units, or their latencies can render code compiled for one VLIW processor incompatible with another, even if they share the same instruction set architecture" (p. 274).

A dynamically scheduled processor has no such problem: there "binary compatibility is preserved across generations" (p. 274). A just-in-time compiler could reschedule the binary for each new chip, but such solutions "introduce additional complexity and are rarely adopted in practice"; so VLIW processors live mainly "in embedded systems, where binaries can be compiled specifically for the target hardware" (p. 274).

Now the second question. The TRACE's compiler knew every unit and every latency and wrote its answer into the bundles, NOPs included. The price is this section's list: a compiler that must find the parallelism, code that carries its empty slots, register names spent on results in flight, stalls on misses the schedule could not foresee — and above all a binary welded to the latencies of one machine.

A laptop must run yesterday's programs on tomorrow's chip, so it keeps the scheduler in hardware and pays for it in area and power. A signal processor or an embedded controller runs one binary on one chip, so it can let the compiler drive. As textbook background, not in the notes: the Texas Instruments C6000 signal processors are VLIWs, and many GPUs and AI accelerators schedule statically in the same spirit. Multiflow's machines did not survive, but its compiler did: Intel, HP, DEC, Fujitsu and others licensed it.

VLIW trades hardware for compiler work: simpler, cheaper, lower-power chips and a large scheduling window, paid for with code size, register names, stalls on unforeseen misses and binaries tied to one implementation.