Very long instruction word (VLIW) is a type of instruction set architecture designed to exploit instruction-level parallelism (ILP) by explicitly specifying, in advance, which instructions execute in parallel. VLIW architectures contrast with superscalar architectures, the predominant approach for exploiting ILP, where hardware dynamically discovers and schedules parallel execution at runtime. VLIW's primary motivation is achieving higher performance without the hardware complexity of superscalar designs. The circuitry needed to repeatedly analyze instruction streams and schedule parallel execution at runtime increases chip area, cost, and power consumption while potentially reducing clock speeds. The name VLIW derives from the instruction format found in almost all implementations, where the compiler bundles operations intended to execute simultaneously into a single, wide instruction word dispatched to execution units as one unit. These words can be extremely wide—implementations have used instruction words of 1 kilobit or more. But this is only a side effect of the natural way to implement a VLIW. The distinguishing feature of a VLIW is that the exact execution order and parallelism are discovered and specified in advance. VLIW shifts the burden of identifying parallelism from hardware to the compiler. This increases compiler complexity substantially, as it must schedule instructions while ensuring correctness, resolving resource conflicts (for execution units, registers, and memory ports), and exploiting the greater parallelism that simpler VLIW hardware exposes.
History The concept of VLIW architecture, and the term VLIW, were invented by Josh Fisher in his research group at Yale University in the early 1980s. His original development of trace scheduling as a compiling method for VLIW was developed when he was a graduate student at New York University. Before VLIW, the notion of prescheduling execution units and instruction-level parallelism in software was well established in the practice of developing horizontal microcode. Fisher's innovations involved developing a compiler that could target horizontal microcode from programs written in an ordinary programming language. He realized that to get good performance and target a wide-issue machine, it would be necessary to find parallelism beyond that generally within a basic block. He also developed region scheduling methods to identify parallelism beyond basic blocks. Trace scheduling is such a method, and involves scheduling the most likely path of basic blocks first, inserting compensating code to deal with speculative motions, scheduling the second most likely trace, and so on, until the schedule is complete. Fisher's second innovation was the notion that the target CPU architecture should be designed to be a reasonable target for a compiler; that the compiler and the architecture for a VLIW processor must be codesigned. This was inspired partly by the difficulty Fisher observed at Yale of compiling for architectures like Floating Point Systems' FPS164, which had a complex instruction set computing (CISC) architecture that separated instruction initiation from the instructions that saved the result, needing very complex scheduling algorithms. Fisher developed a set of principles characterizing a proper VLIW design, such as self-draining pipelines, wide multi-port register files, and memory architectures. These principles made it easier for compilers to emit fast code. The first VLIW compiler was described in a Ph.D. thesis by John Ellis, supervised by Fisher. The compiler was named Bulldog, after Yale's mascot. Fisher left Yale in 1984 to found a startup company, Multiflow, along with cofounders John O'Donnell and John Ruttenberg. Multiflow produced the TRACE series of VLIW minisupercomputers, shipping their first machines in 1987. Multiflow's VLIW could issue 28 operations in parallel per instruction. The TRACE system was implemented in a mix of medium-scale integration (MSI), large-scale integration (LSI), and very large-scale integration (VLSI), packaged in cabinets, a technology obsoleted as it grew more cost-effective to integrate all of the components of a processor (excluding memory) on one chip. Multiflow was too early to catch the following wave, when chip architectures began to allow multiple-issue CPUs. The major semiconductor companies recognized the value of Multiflow technology in this context, so the compiler and architecture were subsequently licensed to most of these firms.
Motivation A processor that executes every instruction one after the other (i.e., a non-pipelined scalar architecture) may use processor resources inefficiently, yielding potential poor performance. The performance can be improved by executing different substeps of sequential instructions simultaneously (termed pipelining), or even executing multiple instructions entirely simultaneously as in superscalar architectures. Further improvement can be achieved by executing instructions in an order different from that in which they occur in a program, termed out-of-order execution. These three methods all raise hardware complexity. Before executing any operations in parallel, the processor must verify that the instructions have no interdependencies. For example, if a first instruction's result is used as a second instruction's input, then they cannot execute at the same time and the second instruction cannot execute before the first. Modern out-of-order processors have increased the hardware resources which schedule instructions and determine interdependencies. In contrast, VLIW executes operations in parallel, based on a fixed schedule, determined when programs are compiled. Since determining the order of execution of operations (including which operations can execute simultaneously) is handled by the compiler, the processor does not need the scheduling hardware that the three methods described above require. Thus, VLIW CPUs offer more computing with less hardware complexity (but greater compiler complexity) than do most superscalar CPUs. This is also complementary to the idea that as many computations as possible should be done before the program is executed, at compile time.
… excerpt ends here. Continue reading the full article.
