Hello to our regular readers!
In part 1, we went through the rise, the promises, and the faceplant of Itanium — now it’s time to move forward. In this next part, we’ll shift the focus from one very expensive lesson to the bigger picture: what VLIW actually became outside of IA-64, where it quietly worked (and still works), and why the idea itself didn’t disappear even after such a loud failure.
And yes, we’ll finally get to the fun stuff — including some unexpectedly successful implementations and a certain console you definitely didn’t expect to see here.
In the Beginning Was the Word — a Very Long Instruction Word
At the core of VLIW lies the idea of a very long instruction word — a bundle of short instructions that the processor executes in parallel within a single clock cycle. This long instruction word can include operations for arithmetic units (such as addition or multiplication), memory loads, and control flow instructions (branches, function calls). All of these are executed simultaneously so that the processor’s functional units remain as busy as possible.
The VLIW architecture is built on a key principle: shifting the responsibility for discovering parallelism onto the compiler. Instead of the processor dynamically analyzing instruction dependencies (as in superscalar CPUs), the compiler does this at compile time. It identifies independent instructions, groups them into bundles, and generates long instruction words for execution.
For this approach to work, a VLIW processor typically includes hardware functional units: ALUs (arithmetic logic units), FPUs (floating-point units), and specialized cores (for example, for multimedia or neural workloads). Each of these units can operate independently, enabling a very high degree of parallelism.
On paper, all of this looks elegant: VLIW simplifies processor design, reduces power consumption by eliminating real-time dependency analysis, and potentially allows for higher clock speeds (since the processor is freed from extra work). In reality, however, Intel Itanium ran at lower clock speeds than its x86 competitors — largely due to its complex microarchitecture and deep pipelines.
And the main issue: the compiler became VLIW’s kryptonite. In real-world applications, where code is complex and dynamic, compilers simply couldn’t optimize and parallelize instructions well enough to fully unlock VLIW’s potential.
Let me throw a small asteroid into the developers’ backyard — or perhaps into the world of “just business” decisions. This is purely my opinion, thinking out loud: instead of focusing on writing high-quality, carefully optimized code, the industry leaned toward patching performance problems with hardware brute force. In x86, more and more transistors were added for things like branch prediction, but modern GPUs already show that hardware no longer delivers massive generational gains. This path is reaching its limits. Optimization — in code and compilers — is where things are heading, not endlessly scaling chiplets, core counts, and clock speeds.
Alright, time to move on to the problems VLIW faced in the real world.
VLIW Problems: Why Didn’t It Go Mainstream?
First — Strong Dependence on the Compiler
Compilation errors or insufficient optimization can cause severe performance drops in VLIW systems. The architecture performs well only in tightly controlled environments, where execution can be predicted and optimized in advance.
Here lies a fundamental issue with the very concept of long instruction words — a rigid binding to a specific instruction layout. VLIW-like architectures use fixed instruction widths, such as 64 or 128 bits, packing multiple operations into a single word. If one of those slots cannot be filled (for example, no independent task is available for a functional unit), it remains unused, leading to inefficient utilization of computing resources.
Unlike x86, where dynamic scheduling can fill execution gaps on the fly, VLIW pipelines are strictly tied to compiler decisions. As a result, some execution units may — and often will — sit idle.
Second — Compatibility and Ecosystem
The poor compatibility with x86 applications was already demonstrated by Itanium. But what if that was more of an implementation problem than a fundamental flaw of VLIW? What if experienced engineers could have built an efficient dynamic binary translator, similar to Apple’s Rosetta?
Expert note: even theoretically, building something like Rosetta for VLIW is extremely difficult, because x86 includes a large number of dependencies and self-managed mechanisms that simply don’t exist in VLIW.
Compatibility issues in the VLIW world also exist internally. There is no single standard. Software written for one VLIW processor may not work on another due to differences in instruction width, compiler implementation, and instruction sets. In other words, portability is difficult even within the VLIW ecosystem itself.
This is not about backward compatibility, but about fundamentally different implementations. In the x86 world, AMD and Intel processors run the same software thanks to instruction-level compatibility (with rare exceptions for proprietary features).
So VLIW faces a double challenge: difficulty interacting with external architectures and a lack of internal standardization. Building a strong ecosystem on such a foundation is extremely hard, especially compared to x86, which has accumulated decades of backward compatibility and offers a stable platform for both developers and users.
Early VLIW Systems: Multiflow TRACE and Intel i860
The first serious attempt to build a VLIW processor came from Multiflow Computer, Inc., founded by a group of engineers including Josh Fisher.
In May 1987, Multiflow introduced the TRACE 7/200 and TRACE 14/200 — mini-supercomputers based on VLIW architecture, capable of executing 7 operations (4 integer/memory, 2 floating-point, and 1 branch) and 14 operations per cycle, respectively. Later, an even more powerful version followed.
Their theoretical performance, given sufficient instruction-level parallelism, was impressive. The Trace Scheduling Compiler analyzed code and grouped independent instructions into long instruction words.
However, the systems were too expensive and niche (targeted mainly at research institutions), and the complexity of programming, combined with competition, left them with no real chance. Even funding from DARPA couldn’t save the company — by 1990, its technologies and patents were acquired by Hewlett-Packard, along with its engineers.
In 1989, Intel released the i860 — arguably the first commercial VLIW processor. It was marketed as a high-performance solution for floating-point workloads such as 3D graphics, scientific computing, and signal processing. Developers, however, had a different experience: programming it was extremely difficult. Without dynamic scheduling, it required perfectly optimized code, and compilers of the time simply couldn’t handle the task.
As a result, the i860 never saw widespread adoption, but it did influence the development of SIMD instructions in later x86 processors. Technologies like MMX and SSE owe part of their design to ideas explored in the i860.
Then came Itanium — the most ambitious (and arguably the loudest) VLIW project in history. Its architecture promised a revolution, but instead, it sank.
VLIW Is Still Alive: From DSPs to PlayStation 2
VLIW never succeeded in the mass market, but it didn’t disappear either. It continues to thrive in areas where the compiler can reliably predict how code will execute — niches where data flows are easy to parallelize.
Digital Signal Processors (DSP): Audio, Video, and Telecom
One of the earliest successful applications of VLIW was in the Texas Instruments TMS320C6x family — high-performance DSPs designed for compute-intensive workloads.
DSPs are flexible and efficient. Unlike hardwired analog circuits, they can be reprogrammed for different tasks and are less sensitive to environmental factors.
A typical DSP pipeline looks like this:
- An analog-to-digital converter (ADC) transforms an external signal (such as voice) into digital form.
- The DSP processes it — filtering, compressing, enhancing quality.
- A digital-to-analog converter (DAC) converts it back into analog form (for example, sound through speakers).
Why does VLIW work so well here? Because real-time processing requires guaranteed execution within strict time limits. VLIW allows many operations per cycle, delivering both high efficiency and predictable performance.
Companies like Texas Instruments and Qualcomm have long used VLIW in signal processors. Qualcomm’s Hexagon architecture, for example, powers DSPs in Snapdragon chips, handling audio, imaging, and AI acceleration. It works because the workloads are predictable and compilers know how to parallelize them effectively.
PlayStation 2 and Its Secret
If you’ve ever owned a Sony PlayStation 2, you’ve already encountered VLIW — whether you realized it or not. The console is built around the Emotion Engine, a system-on-chip developed by Toshiba and used by Sony.
As an SoC, it includes multiple components:
- A 64-bit CPU (MIPS R5900 architecture with SIMD extensions);
- Specialized engines, including vector co-processors (VPU0 and VPU1) for graphics and physics;
- A DMA controller for fast data transfers;
- A memory interface;
- Cache: 16 KB instruction cache, 8 KB data cache, plus 16 KB of fast scratchpad memory.
The Emotion Engine is essentially a custom MIPS-based chip combining a CPU with specialized processing blocks, designed primarily for 3D workloads.
It features two vector units — VU0 and VU1 — both based on VLIW architecture, capable of executing multiple operations per cycle.
VU1 is a fully autonomous SIMD/VLIW processor that inherits all architectural features of VU0 while introducing additional functionality. These additions are tied to its role as the geometry processor for the Graphics Synthesizer (GS), allowing it to integrate more closely with it. The key addition is an extra functional unit called the Elementary Function Unit (EFU). The EFU consists of one FMAC (floating-point multiply-accumulate unit) and one FDIV (floating-point division unit), similar to the main CPU’s FPU. The EFU handles basic calculations required for geometry processing.
Another key difference between VU1 and VU0 is memory capacity. VU1 has 16 KB of data memory and 16 KB of instruction memory, while VU0 has only 8 KB of each. The larger data memory is critical, since VU1, acting as a geometry processor, handles significantly more data than VU0.
In addition, VU1 supports multiple ways of sending data to the GIF (and further to the GS). Like VU0, it can send display lists through the main 128-bit bus. VU1’s VIF can also transfer data directly to the GIF. Finally, there is a direct connection between VU1’s 16 KB data memory and the GIF. This allows VU1 to work with display lists in its local memory, while the DMAC (Direct Memory Access Controller) transfers results directly to the GIF.
Expert note: he Emotion Engine executes multiple instructions at once (VLIW), with some of them operating in parallel data-processing mode (SIMD).
In the context of the VU0 and VU1 vector units, this means the processor executes long 64-bit instructions split into two 32-bit parts. These parts are executed in parallel by two execution units: the upper and the lower. The upper unit operates in SIMD mode, meaning it performs a single instruction on multiple data elements simultaneously (for example, four floating-point additions or multiplications at once). The lower unit does not use SIMD and instead handles more specialized tasks such as division, load/store operations, branching, and other control-related instructions.
Both units combine VLIW and SIMD: long instructions are split into parallel operations, with one unit handling vectorized math and another handling control, memory, or division tasks.
This design made the Emotion Engine powerful but extremely complex. Developers had to carefully optimize code to fully utilize it. Early PS2 games didn’t look much better than PlayStation 1 titles because developers hadn’t yet mastered the hardware.
Over time, studios like Naughty Dog and Santa Monica Studio learned to extract its full potential — often writing low-level code directly for the vector units. Late-generation titles like God of War II, Metal Gear Solid 3, Gran Turismo 4, Black, and Shadow of the Colossus showcased what the system was truly capable of.
Transmeta Crusoe — A Different Approach
In the 2000s, Transmeta took a different path with its Crusoe and Efficeon processors. These chips used VLIW combined with dynamic x86 translation, aiming to run standard software like Windows while consuming far less power.
There were even consumer devices based on them, including ultraportable laptops.
However, like Itanium, Transmeta’s solutions struggled. Performance under x86 translation lagged behind native x86 processors, and software often required additional optimization. Ultimately, Transmeta couldn’t compete with Intel and AMD and shut down in 2009.
Conclusion
The story of VLIW is the story of an architecture that could have changed the industry — but didn’t. Despite its elegance and strong theoretical advantages in performance and efficiency, it never became mainstream.
The core issue remains the same: dependence on a compiler that must perfectly optimize code for execution.
Instead of investing deeply in software optimization, the industry chose to chase hardware-driven performance gains — a path that is now showing its limits. VLIW, in many ways, was simply unlucky: caught between imperfect implementations and unfavorable timing.
The failure of Itanium shows that even massive investments and industry giants like Intel and HP cannot overcome fundamental architectural limitations — especially without a strong ecosystem.
But VLIW’s legacy lives on, particularly in specialized domains where compilers can fully exploit its strengths: DSPs, mobile processors, and other highly parallel workloads.
Thanks for making it through this long read. If you spot any mistakes, feel free to point them out — it’s the fastest way to improve. And let me know if you’d like to see a deep dive into another architecture.
