VLIW architectures

What Is VLIW?

Why VLIW? The Design Philosophy

Traditional superscalar processors use complex hardware logic:

Out-of-order execution engines to find parallelism at runtime
Register renaming logic to eliminate false dependencies
Reservation stations and reorder buffers to track in-flight instructions
Wakeup/select logic that consumes significant power and area

VLIW says: "What if we move all this complexity to the compiler?"

WHY this trade-off makes sense:

Compile-time analysis has unlimited time and global code visibility
Hardware complexity grows super-linearly with issue width (O(n²) for many structures)
Power consumption of dynamic scheduling hardware is substantial
Simpler hardware → lower power, higher clock speeds, easier verification

VLIW Instruction Format

Formula VLIW Instruction Word Structure

A VLIW instruction word contains multiple operation slots, each targeting a specific functional unit:

$\text{VLIW Instruction} = [\text{Op}_1 | \text{Op}_2 | \text{Op}_3 | \cdots | \text{Op}_n]$

Where each $\text{Op}_i$ can be:

A real operation (add, load, branch, etc.)
A NOP (no operation) if no parallel work exists

Example 4-slot machine (used throughout this note): We define a concrete 4-issue VLIW with exactly these functional units and slots:

\text{Slot 0:} &\quad \text{Integer ALU operation (ALU 1)} \\ \text{Slot 1:} &\quad \text{Integer ALU / Multiply operation (ALU 2)} \\ \text{Slot 2:} &\quad \text{Memory operation (single load/store unit)} \\ \text{Slot 3:} &\quad \text{Branch OR Floating-point operation} \end{aligned}$$ **Important constraint:** With **one memory unit**, at most **one load/store per instruction**. This constraint drives all the worked examples below.

WHY fixed slots? Hardware can decode and route operations to functional units with simple combinational logic—no complex dependency matrices or dynamic dispatch logic needed.

Deriving Code Density Impact

If we have a VLIW machine with $n$ operation slots per instruction:

Best case (full parallelism): $n$ operations per instruction word Worst case (no parallelism): 1 real operation + $(n-1)$ NOPs per instruction word

Code density efficiency compared to sequential RISC: $\text{Efficiency} = \frac{\text{Operations executed}}{\text{Instruction bits transmitted}} = \frac{k}{n} \times \frac{b_{\text{RISC}}}{b_{\text{VLIW}}}$

Where:

$k$ = average operations per VLIW instruction (1 ≤ k ≤ n)
$b_{\text{RISC}}$ = bits per RISC instruction (~32 bits)
$b_{\text{VLIW}}$ = bits per VLIW instruction ( $n \times b_{\text{op}}$ , typically 128-512 bits)

WHY this matters: If parallelism is low, you pay the code size cost of NOPs while getting sequential performance. VLIW lives or dies by the compiler's ability to find parallelism.

Worked example Example: A 4-Issue VLIW Machine (1 memory unit, 2 integer ALUs, 1 branch/FP)

Using the concrete 4-slot machine defined above: at most one memory operation per instruction because there is a single load/store unit.

High-parallelism loop (array addition):

for (int i = 0; i < 100; i++) {
   c[i] = a[i] + b[i];
}

Compiled VLIW code (steady state, software-pipelined across iterations): Because only ONE memory op issues per cycle, loads and stores are spread across cycles. The two integer ALUs let us overlap address/add work while the single memory port streams data.

Slot layout:  [ ALU1        | ALU2         | MEMORY (1 port) | BR/FP ]
Instr 1:      [ NOP         | NOP          | LD r1,a[i]      | NOP   ]
Instr 2:      [ NOP         | NOP          | LD r2,b[i]      | NOP   ]
Instr 3:      [ ADD r5,r1,r2| NOP          | LD r3,a[i+1]    | NOP   ]
Instr 4:      [ NOP         | NOP          | ST c[i],r5      | NOP   ]
Instr 5:      [ NOP         | NOP          | LD r4,b[i+1]    | NOP   ]
Instr 6:      [ ADD r6,r3,r4| NOP          | LD r7,a[i+2]    | NOP   ]
Instr 7:      [ NOP         | NOP          | ST c[i+1],r6    | NOP   ]

WHY each step:

The single memory port is the bottleneck: every load/store must go in a separate instruction.
The two integer ALU slots let compute overlap with the memory stream, so ADDs "hide under" memory traffic.
This example is memory-bound: the ALU slots are mostly NOP because there simply is not enough compute to fill them relative to memory operations.

Lesson: VLIW cannot exceed the hardware's resource limits. With one memory port, this loop's throughput is limited to roughly one memory op per cycle regardless of how many ALU slots exist.

Low-parallelism code (dependent chain):

int fib = 1, prev = 1;
for (int i = 0; i < 10; i++) {
   int temp = fib;
   fib = fib + prev;
   prev = temp;
}

Compiled VLIW code (one iteration):

Instr 1:  [ MOV r3,r1 | NOP | NOP | NOP ]        // temp = fib
Instr 2:  [ ADD r1,r1,r2 | NOP | NOP | NOP ]     // fib = fib + prev (depends on r1)
Instr 3:  [ MOV r2,r3 | NOP | NOP | NOP ]        // prev = temp

Efficiency: 3 real operations / 12 slots = 25% slot utilization. Terrible!

WHY the difference? The second example has true data dependencies that prevent parallel execution. VLIW cannot create parallelism; it can only exploit what exists.

The Compiler's Role: Static Scheduling

The VLIW compiler must perform sophisticated analysis:

1. Dependency Analysis

Data dependencies:

RAW (Read After Write): True dependency, must preserve order
WAR (Write After Read): Anti-dependency, can eliminate with register renaming
WAW (Write After Write): Output dependency, can eliminate with register renaming

WHY the compiler handles this: In superscalar processors, hardware register renaming eliminates WAR/WAW. In VLIW, the compiler must rename registers itself during scheduling.

Formula Minimum Initiation Interval (Modulo Scheduling)

For software-pipelined loops, the minimum initiation interval $\text{II}_{\min}$ (cycles between starting successive iterations) is the maximum of two lower bounds:

$\text{II}_{\min} = \max\!\left(\text{ResMII},\ \text{RecMII}\right)$

(1) Resource-constrained bound (ResMII): For each resource type $r$ (e.g., memory port, ALU), if the loop body needs $u_r$ uses of a resource that has $c_r$ copies: $\text{ResMII} = \max_{r}\ \left\lceil \frac{u_r}{c_r} \right\rceil$

(2) Recurrence-constrained bound (RecMII): Taken as the maximum over all dependency cycles $C$ in the dependency graph. For a cycle $C$ with total latency $\text{Lat}(C)$ (sum of operation latencies around the cycle) and total iteration distance $\text{Dist}(C)$ (sum of iteration distances of the edges): $\text{RecMII} = \max_{C}\ \left\lceil \frac{\text{Lat}(C)}{\text{Dist}(C)} \right\rceil$

Derivation: If an operation at iteration $i$ depends (through cycle $C$ ) on results produced $\text{Dist}(C)$ iterations earlier, and traversing $C$ takes $\text{Lat}(C)$ cycles, then over $\text{Dist}(C)$ iterations we must allow at least $\text{Lat}(C)$ cycles, i.e. $\ge \text{Lat}(C)/\text{Dist}(C)$ cycles per iteration. Taking the ceiling gives an integer cycle count, and the max over all cycles ensures every recurrence is satisfied.

2. Software Pipelining (Modulo Scheduling)

The most powerful technique for VLIW loop performance:

Traditional loop execution (sequential):

Iteration 1: [Load A] → [Compute] → [Store]
Iteration 2:                          [Load A] → [Compute] → [Store]  
Iteration 3:                                [Load A] → ...

Software pipelined (overlapped):

Prologue:    [Load A for iter 1]
Steady:      [Load A for iter 2] [Compute iter 1] [Store iter 0]
             [Load A for iter 3] [Compute iter 2] [Store iter 1]
             [Load A for iter 4] [Compute iter 3] [Store iter 2]
Epilogue:                [Compute iter n] [Store iter n-1]
                                [Store iter n]

WHY this works: Different iterations occupy different pipeline stages within the same instruction cycle, maximizing functional unit utilization.

Worked example Software Pipelining Example (respecting the 1-memory-port, 4-slot machine)

Original loop:

for (i = 0; i < 100; i++) {
   x = a[i] * b[i];      // 4-cycle multiply on ALU2
   c[i] = x + d[i];      // 1-cycle add on ALU1
}

Resource accounting for II: Per iteration we need 3 memory ops (LD a, LD b, LD d, ST c = actually 4 memory ops), 1 multiply, 1 add.

Memory ops needed per iteration: LD a, LD b, LD d, ST c = 4 memory ops, one memory port → $\text{ResMII} = \lceil 4/1 \rceil = 4$ .
There is no loop-carried recurrence (each $c[i]$ is independent), so $\text{RecMII}=1$ .
Therefore $\text{II}_{\min} = \max(4,1) = 4$ . The single memory port forces II = 4, not II = 1.

Software-pipelined steady state (II = 4 cycles per iteration):

Slot layout:  [ ALU1(add)      | ALU2(mul)          | MEMORY (1 port) | BR/FP ]
Cycle 1:      [ ADD c-stage(i-1)| MUL x[i],a[i],b[i] | LD a[i+1]       | NOP   ]
Cycle 2:      [ NOP             | NOP                | LD b[i+1]       | NOP   ]
Cycle 3:      [ NOP             | NOP                | LD d[i+1]       | NOP   ]
Cycle 4:      [ NOP             | NOP                | ST c[i-1]       | NOP   ]

Each iteration consumes 4 cycles because the memory port (not the multiply latency) is the binding constraint. The 4-cycle multiply latency is fully hidden inside this 4-cycle window.

WHY step-by-step:

Cycle 1: Start this iteration's multiply AND finish the previous iteration's add, while the memory port loads the next a.
Cycles 2–3: Memory port streams b and d; ALUs idle because the multiply is still in flight (latency 4) and no add is ready.
Cycle 4: Memory port stores a completed result.
Note: no slot ever holds two operations, and at most one memory op per cycle, honoring the defined issue width.

Total cycles (approx): prologue (~4) + 100 × 4 (steady) + epilogue (~4) ≈ 408 cycles.

Contrast — if the machine had 2 memory ports (a different design), $\text{ResMII} = \lceil 4/2 \rceil = 2$ , halving the loop time. This shows how VLIW performance is dictated by hardware resource counts, which the compiler must respect exactly.

3. Predication

VLIW architectures heavily use predication (conditional execution) to eliminate branches:

Instead of:

if (x > 0)
    a = b + c;
else
    a = b - c;

VLIW with predication:

cmp.gt p1,p2 = x,0           // p1 = (x>0), p2 = !(x>0)
(p1) add a = b, c            // execute if p1 is true
(p2) sub a = b, c            // execute if p2 is true

WHY predication is critical for VLIW:

Branches prevent software pipelining (can't overlap iterations across conditional boundaries)
Branch mispredictions are expensive (no speculative execution hardware)
Predication converts control dependencies into data dependencies, enabling more parallelism

VLIW vs. Superscalar: The Trade-offs

Aspect	VLIW	Superscalar
Parallelism discovery	Compile-time (static)	Run-time (dynamic)
Hardware complexity	Low (simple dispatch)	High (OoO engines)
Power efficiency	Better (no speculation)	Worse (speculation overhead)
Code portability	Poor (ISA tied to # units)	Good (HW adapts)
Code size	Larger (NOPs when low ILP)	Smaller (dense encoding)
Performance on irregular code	Poor	Better (dynamic adaptation)
Compiler burden	Extreme	Moderate

WHY VLIW struggled in general-purpose CPUs: The "VLIW dilemma": Adding more functional units for future performance requires changing the ISA (more operation slots), breaking backward compatibility. Intel Itanium tried to solve this with explicit parallelism bits and predication, but compiler technology couldn't consistently find enough ILP in general-purpose code.

WHERE VLIW succeeded:

DSPs (Texas Instruments C6x): Signal processing has abundant data parallelism
Embedded media processors: Where code is compiled once for a specific processor
Some GPU shader cores (historical, e.g. AMD TeraScale VLIW5/VLIW4): These early GPUs did pack independent operations into a VLIW bundle per lane. Note: modern GPUs have largely moved away from VLIW toward scalar SIMT designs (see mistake below).

Common mistake Common Misconception: "VLIW Always Means More Performance"

The wrong intuition: "More operations per instruction = faster programs!" Why it feels right: Parallelism does increase throughput when it exists.

The reality: VLIW only helps if the compiler can find independent operations and the hardware has the resources (ports, units) to execute them. On code with limited ILP (linked lists, pointer chasing, recursion) or with resource bottlenecks (one memory port), VLIW wastes instruction bits on NOPs while performing near-sequentially.

The fix: VLIW is a domain-specific optimization. It excels on:

Regular loops with predictable memory access (arrays, matrix operations)
Computations with high arithmetic intensity
Code without unpredictable branches It struggles on:
Pointer-heavy data structures
Code with many unpredictable branches
Workloads with poor locality or limited memory ports

Quantitative example: Intel Itanium (IA-64) had 6-wide VLIW but often achieved <2 IPC on SPECint (integer benchmarks with irregular code), while 4-wide superscalar processors achieved 2-3 IPC through dynamic scheduling.

Common mistake Misconception: "Modern GPUs are VLIW machines"

The wrong idea: "GPUs issue wide instructions, so they must be VLIW with static scheduling like Itanium."

Why it feels right: GPUs do exploit massive parallelism, and some historical GPUs (AMD TeraScale VLIW5/VLIW4, ~2007–2012) genuinely used VLIW bundles.

The reality: Contemporary GPUs (NVIDIA since Fermi, AMD GCN/RDNA) use SIMT (Single Instruction, Multiple Threads) with hardware-driven, dynamic warp/wavefront scheduling. Parallelism comes from running many independent threads in lock-step lanes, not from a compiler packing independent operations into one wide instruction word. The scheduling of which warp runs each cycle is a runtime hardware decision.

The fix: Distinguish two different ideas:

VLIW: compiler statically packs independent operations into one instruction; hardware scheduling is trivial.
SIMT: hardware dynamically schedules many threads executing the same scalar instruction across lanes. These are not the same mechanism, even though both achieve high parallelism.

Memory Disambiguation: The Achilles Heel

Consider:

for (i = 0; i < N; i++) {
    a[i] = b[i] + c[i];
    d[i] = e[i] * f[i];
}

The compiler sees two independent statements and wants to execute them in parallel. But what if a and e overlap in memory? The store to a[i] could affect the load from e[i].

In superscalar: Hardware performs memory disambiguation at runtime, detecting aliasing dynamically.

In VLIW: The compiler must either:

Prove independence through static analysis (often impossible with pointers)
Insert runtime checks (defeating the simplicity advantage)
Assume independence and risk incorrect execution

WHY this limits VLIW: Memory aliasing is undecidable in general. Conservative assumptions kill parallelism; aggressive assumptions risk bugs.

Formula The ILP Ceiling

Empirical studies show that average instruction-level parallelism in general-purpose code:

$\text{ILP}_{\text{available}} \approx 2.5 \text{ to } 4\text{ operations per cycle}$

Even with perfect disambiguation and infinite resources. This is due to:

True data dependencies (RAW)
Control dependencies (branches)
Memory dependencies (aliasing)

Amdahl's Law for VLIW: If fraction $f$ of code is perfectly parallelizable to $n$ ways, and fraction $(1-f)$ is sequential:

$\text{Speedup} = \frac{1}{(1-f) + \frac{f}{n}}$

For VLIW with $n=8$ issue width and $f=0.6$ parallelizable: $\text{Speedup} = \frac{1}{0.4 + 0.075} = 2.1\times$

You built an 8-wide machine but got 2× speedup. The NOPs in those 6 wasted slots represent power and code size cost with no benefit.

Recall Feynman Explan

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho yaar, VLIW ka core idea bahut simple aur elegant hai. Traditional superscalar processors mein hardware ko real-time mein figure out karna padta hai ki kaunse instructions parallel run ho sakte hain — iske liye bahut complex logic chahiye, jaise out-of-order execution engines, register renaming, reservation stations. Ye sab power aur die area khaata hai. VLIW bolta hai ki "yaar, ye kaam compiler ko de do!" Compiler compile-time pe hi dependencies analyze karke independent operations ko ek single wide instruction mein pack kar deta hai. Uss "meal prep" wale analogy ko yaad rakho — chef (hardware) ko frantically coordinate karne ki zaroorat nahi, kyunki poore meal kits (VLIW instructions) pehle se ready hote hain, sab pre-sorted.

Ab ye kyun matter karta hai? Do main reasons. Pehla, compiler ke paas unlimited time aur poore code ka global view hota hai — jabki hardware ke paas bas milliseconds hote hain aur limited window dikhta hai. Toh compiler zyada smart scheduling kar sakta hai. Dusra, hardware complexity issue-width ke saath super-linearly badhti hai (kai structures ke liye O(n²)), toh jab aap ye complexity hataate ho, tab hardware simple, low-power, high-clock-speed, aur easily verifiable ban jaata hai. Har VLIW instruction word mein fixed operation slots hote hain — jaise humare 4-issue example mein Slot 0 aur 1 integer ALU ke liye, Slot 2 memory ke liye, Slot 3 branch/floating-point ke liye. Ek hi memory unit hone ki wajah se ek instruction mein sirf ek load/store allowed hai — ye constraint aage ke examples mein bahut important hai.

Ek trade-off bhi samajh lo taaki poori picture clear ho. Agar compiler ko parallel work nahi milta, toh usse slots mein NOP (no operation) daalna padta hai — matlab wasted bits. Best case mein saare n slots full hote hain, worst case mein sirf 1 real operation aur baaki NOPs. Isliye code density efficiency important metric hai — kitne actual operations execute ho rahe hain versus kitne instruction bits transmit ho rahe hain. Toh VLIW ka poora game hai: hardware ko simple banao, complexity compiler pe shift karo, lekin dhyaan rakho ki agar compiler achhe se schedule na kar paaye toh NOPs se performance aur code density dono suffer karte hain.

What Is VLIW?

Why VLIW? The Design Philosophy

VLIW Instruction Format

Deriving Code Density Impact

The Compiler's Role: Static Scheduling

1. Dependency Analysis

2. Software Pipelining (Modulo Scheduling)

3. Predication

VLIW vs. Superscalar: The Trade-offs

Memory Disambiguation: The Achilles Heel

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Advanced Microarchitecture