Very long instruction word

Very long instruction word (VLIW) refers to instruction set architectures designed to exploit instruction level parallelism (ILP). Whereas conventional central processing units (CPU, processor) mostly allow programs to specify instructions to execute in sequence only, a VLIW processor allows programs to explicitly specify instructions to execute in parallel. This design is intended to allow higher performance without the complexity inherent in some other designs.

Overview[edit]

The traditional means to improve performance in processors include dividing instructions into substeps so the instructions can be executed partly at the same time (termed pipelining), dispatching individual instructions to be executed independently, in different parts of the processor (superscalar architectures), and even executing instructions in an order different from the program (out-of-order execution).^[1] These methods all complicate hardware (larger circuits, higher cost and energy use) because the processor must make all of the decisions internally for these methods to work. In contrast, the VLIW method depends on the programs providing all the decisions regarding which instructions to execute simultaneously and how to resolve conflicts. As a practical matter, this means that the compiler (software used to create the final programs) becomes more complex, but the hardware is simpler than in many other means of parallelism.

Motivation[edit]

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.^[1]

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.^[1] This is also complementary to the idea that as many computations as possible should be done before the program is executed, at compile time.

Design[edit]

In superscalar designs, the number of execution units is invisible to the instruction set. Each instruction encodes one operation only. For most superscalar designs, the instruction width is 32 bits or fewer.

In contrast, one VLIW instruction encodes multiple operations, at least one operation for each execution unit of a device. For example, if a VLIW device has five execution units, then a VLIW instruction for the device has five operation fields, each field specifying what operation should be done on that corresponding execution unit. To accommodate these operation fields, VLIW instructions are usually at least 64 bits wide, and far wider on some architectures.

For example, the following is an instruction for the Super Harvard Architecture Single-Chip Computer (SHARC). In one cycle, it does a floating-point multiply, a floating-point add, and two autoincrement loads. All of this fits in one 48-bit instruction:

f12 = f0 * f4, f8 = f8 + f12, f0 = dm(i0, m3), f4 = pm(i8, m9);

Since the earliest days of computer architecture,^[2] some CPUs have added several arithmetic logic units (ALUs) to run in parallel. Superscalar CPUs use hardware to decide which operations can run in parallel at runtime, while VLIW CPUs use software (the compiler) to decide which operations can run in parallel in advance. Because the complexity of instruction scheduling is moved into the compiler, complexity of hardware can be reduced substantially.^{[clarification needed]}

A similar problem occurs when the result of a parallelizable instruction is used as input for a branch. Most modern CPUs guess which branch will be taken even before the calculation is complete, so that they can load the instructions for the branch, or (in some architectures) even start to compute them speculatively. If the CPU guesses wrong, all of these instructions and their context need to be flushed and the correct ones loaded, which takes time.

This has led to increasingly complex instruction-dispatch logic that attempts to guess correctly, and the simplicity of the original reduced instruction set computing (RISC) designs has been eroded. VLIW lacks this logic, and thus lacks its energy use, possible design defects, and other negative aspects.

In a VLIW, the compiler uses heuristics or profile information to guess the direction of a branch. This allows it to move and preschedule operations speculatively before the branch is taken, favoring the most likely path it expects through the branch. If the branch takes an unexpected way, the compiler has already generated compensating code to discard speculative results to preserve program semantics.

Vector processor cores (designed for large one-dimensional arrays of data called vectors) can be combined with the VLIW architecture such as in the Fujitsu FR-V microprocessor, further increasing throughput and speed.^{[citation needed]}

History[edit]

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.^[3] 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. Before Fisher the theoretical aspects of what would be later called VLIW were developed by the Soviet computer scientist Mikhail Kartsev^[4] based on his Sixties work on military-oriented M-9 and M-10 computers. His ideas were later developed and published as a part of a textbook^[5] two years before Fisher’s seminal paper, but because of the Iron Curtain and because Kartsev’s work was mostly military-related it remained largely unknown in the West.

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.^[6]

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.^{[clarification needed]} 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.

Implementations[edit]

Cydrome was a company producing VLIW numeric processors using emitter-coupled logic (ECL) integrated circuits in the same timeframe (late 1980s). This company, like Multiflow, failed after a few years.

One of the licensees of the Multiflow technology is Hewlett-Packard, which Josh Fisher joined after Multiflow’s demise. Bob Rau, founder of Cydrome, also joined HP after Cydrome failed. These two would lead computer architecture research at Hewlett-Packard during the 1990s.

Along with the above systems, during the same time (1989–1990), Intel implemented VLIW in the Intel i860, their first 64-bit microprocessor, and the first processor to implement VLIW on one chip.^[7] This processor could operate in both simple RISC mode and VLIW mode:

In the early 1990s, Intel introduced the i860 RISC microprocessor. This simple chip had two modes of operation: a scalar mode and a VLIW mode. In the VLIW mode, the processor always fetched two instructions and assumed that one was an integer instruction and the other floating-point.^[7]

The i860’s VLIW mode was used extensively in embedded digital signal processor (DSP) applications since the application execution and datasets were simple, well ordered and predictable, allowing designers to fully exploit the parallel execution advantages enabled by VLIW. In VLIW mode, the i860 could maintain floating-point performance in the range of 20-40 double-precision MFLOPS; a very high value for its time and for a processor running at 25-50Mhz.

In the 1990s, Hewlett-Packard researched this problem as a side effect of ongoing work on their PA-RISC processor family. They found that the CPU could be greatly simplified by removing the complex dispatch logic from the CPU and placing it in the compiler. Compilers of the day were far more complex than those of the 1980s, so the added complexity in the compiler was considered to be a small cost.

VLIW CPUs are usually made of multiple RISC-like execution units that operate independently. Contemporary VLIWs usually have four to eight main execution units. Compilers generate initial instruction sequences for the VLIW CPU in roughly the same manner as for traditional CPUs, generating a sequence of RISC-like instructions. The compiler analyzes this code for dependence relationships and resource requirements. It then schedules the instructions according to those constraints. In this process, independent instructions can be scheduled in parallel. Because VLIWs typically represent instructions scheduled in parallel with a longer instruction word that incorporates the individual instructions, this results in a much longer opcode (termed very long) to specify what executes on a given cycle.

Examples of contemporary VLIW CPUs include the TriMedia media processors by NXP (formerly Philips Semiconductors), the Super Harvard Architecture Single-Chip Computer (SHARC) DSP by Analog Devices, the ST200 family by STMicroelectronics based on the Lx architecture (designed in Josh Fisher’s HP lab by Paolo Faraboschi), the FR-V from Fujitsu, the BSP15/16^[8] from Pixelworks, the CEVA-X DSP from CEVA, the Jazz DSP from Improv Systems, the HiveFlex^[9] series from Silicon Hive, and the MPPA Manycore family by Kalray. The Texas Instruments TMS320 DSP line has evolved, in its C6000 family, to look more like a VLIW, in contrast to the earlier C5000 family. These contemporary VLIW CPUs are mainly successful as embedded media processors for consumer electronic devices.

VLIW features have also been added to configurable processor cores for system-on-a-chip (SoC) designs. For example, Tensilica’s Xtensa LX2 processor incorporates a technology named Flexible Length Instruction eXtensions (FLIX) that allows multi-operation instructions. The Xtensa C/C++ compiler can freely intermix 32- or 64-bit FLIX instructions with the Xtensa processor’s one-operation RISC instructions, which are 16 or 24 bits wide. By packing multiple operations into a wide 32- or 64-bit instruction word and allowing these multi-operation instructions to intermix with shorter RISC instructions, FLIX allows SoC designers to realize VLIW’s performance advantages while eliminating the code bloat of early VLIW architectures.
The Infineon Carmel DSP is another VLIW processor core intended for SoC. It uses a similar code density improvement method called configurable long instruction word (CLIW).^[10]

Outside embedded processing markets, Intel’s Itanium IA-64 explicitly parallel instruction computing (EPIC) and Elbrus 2000 appear as the only examples of a widely used VLIW CPU architectures. However, EPIC architecture is sometimes distinguished from a pure VLIW architecture, since EPIC advocates full instruction predication, rotating register files, and a very long instruction word that can encode non-parallel instruction groups. VLIWs also gained significant consumer penetration in the graphics processing unit (GPU) market, though both Nvidia and AMD have since moved to RISC architectures to improve performance on non-graphics workloads.

ATI Technologies’ (ATI) and Advanced Micro Devices’ (AMD) TeraScale microarchitecture for graphics processing units (GPUs) is a VLIW microarchitecture.

In December 2015, the first shipment of PCs based on VLIW CPU Elbrus-4s was made in Russia.^[11]

The Neo by REX Computing is a processor consisting of a 2D mesh of VLIW cores aimed at power efficiency.^[12]

The Elbrus 2000 (Russian: Эльбрус 2000) and its successors are Russian 512-bit wide VLIW microprocessors developed by Moscow Center of SPARC Technologies (MCST) and fabricated by TSMC.

Backward compatibility[edit]

When silicon technology allowed for wider implementations (with more execution units) to be built, the compiled programs for the earlier generation would not run on the wider implementations, as the encoding of binary instructions depended on the number of execution units of the machine.

Transmeta addressed this issue by including a binary-to-binary software compiler layer (termed code morphing) in their Crusoe implementation of the x86 architecture. This mechanism was advertised to basically recompile, optimize, and translate x86 opcodes at runtime into the CPU’s internal machine code. Thus, the Transmeta chip is internally a VLIW processor, effectively decoupled from the x86 CISC instruction set that it executes.

Intel’s Itanium architecture (among others) solved the backward-compatibility problem with a more general mechanism. Within each of the multiple-opcode instructions, a bit field is allocated to denote dependency on the prior VLIW instruction within the program instruction stream. These bits are set at compile time, thus relieving the hardware from calculating this dependency information. Having this dependency information encoded in the instruction stream allows wider implementations to issue multiple non-dependent VLIW instructions in parallel per cycle, while narrower implementations would issue a smaller number of VLIW instructions per cycle.

Another perceived deficiency of VLIW designs is the code bloat that occurs when one or more execution unit(s) have no useful work to do and thus must execute No Operation NOP instructions. This occurs when there are dependencies in the code and the instruction pipelines must be allowed to drain before later operations can proceed.

Since the number of transistors on a chip has grown, the perceived disadvantages of the VLIW have diminished in importance. VLIW architectures are growing in popularity, especially in the embedded system market, where it is possible to customize a processor for an application in a system-on-a-chip.

See also[edit]

• Explicitly parallel instruction computing (EPIC)
• Elbrus (computer)
• Itanium
• Movidius (SHAVE core)
• Single instruction, multiple data
• Single instruction, multiple threads
• Transport triggered architecture (TTA)

References[edit]

External links[edit]

• Paper That Introduced VLIWs
• Book on the history of Multiflow Computer, VLIW pioneering company
• ISCA «Best Papers» Retrospective On Paper That Introduced VLIWs Archived 2012-03-10 at the Wayback Machine
• VLIW and Embedded Processing
• FR500 VLIW-architecture High-performance Embedded Microprocessor
• Historical background for EPIC instruction set architectures
• DIS: an Architecture for fast LISP execution. A similar VLIW architecture, with a parallelizing compiler directed toward LISP.

Архитектура сверхдлинного командного слова (VLIW — Very Long Instruction Word) берет свое начало от параллельного микрокода, применявшегося еще на заре вычислительной техники, и от суперкомпьютеров Control Data CDC6600 и IBM 360/91. В 1970 году многие вычислительные системы оснащались дополнительными векторными сигнальными процессорами, использующими VLIW-подобные длинные инструкции, прошитые в ПЗУ. Эти процессоры применялись для выполнения быстрого преобразования Фурье и других вычислительных алгоритмов. Первыми настоящими VLIW-компьютерами стали мини-суперкомпьютеры, выпущенные в начале 1980 года компаниями MultiFlow, Culler и Cydrome, но они не имели коммерческого успеха. Планировщик вычислений и программная конвейризация были предложены Фишером и Рау (Cydrome). Сегодня это является основой технологии VLIW-компилятора.

Первый VLIW-компьютер компании MultiFlow 7/300 использовал два арифметико-логических устройства для целых чисел, два АЛУ для чисел с плавающей точкой и блок логического ветвления — все это было собрано на нескольких микросхемах. Его 256bit командное слово содержало восемь 32bit кодов операций. Модули для обработки целых чисел могли выполнять две операции за один такт длиной 130 ns (т.е. всего четыре при двух АЛУ), что при обработке целых чисел обеспечивало быстродействие около 30 MIPS. Можно было также комбинировать аппаратные решения так, чтобы получать из или 256bit, или 1024bit вычислительные машины. Первый VLIW-компьютер Cydrome Cydra-5 использовал 256bit инструкцию и специальный режим, обеспечивающий выполнение команд как последовательности из шести 40bit операций, поэтому его компиляторы могли генерировать смесь параллельного кода и обычного последовательного. Существует мнение, что в то время, как эти VLIW-ВМ использовали несколько микросхем, процессор Intel i860 стал первым VLIW-процессором на одной микросхеме. Однако, i860 можно отнести к VLIW достаточно условно — по сути у него есть всего лишь программно-управляемое спаривание инструкций, в отличие от более позднего программно-неуправляемого, ставшего частью суперскалярных процессоров. В качестве исторической справки также хотелось бы упомянуть компьютеры фирмы FPS (AP-120B, AP-190L и все более поздние под маркой FPS), также основанные на VLIW-архитектуре, которые были в свое время достаточно распространенными и успешными на рынке. Кроме этого, существовали такие «канонические» машины, как М10 и М13 Карцева, а также «Эльбрус-3» — при всем «неуспехе» последнего проекта, он все же явился этапом VLIW. Вообще, быстродействие VLIW-процессора в большей степени зависит от компилятора, нежели от аппаратуры, поскольку здесь эффект от оптимизации последовательности операций превышает результат, возникающий от повышения частоты.

Относительно недавно мы были свидетелями «противостояния» CISC против RISC, а теперь уже намечается новое «сражение» — VLIW против RISC. Строго говоря, VLIW и суперскалярный RISC — никак не антагонисты, ни в коей мере. Справедливости ради необходимо отметить, что последние — это вовсе не «внешнеархитектурное» свойство, а просто некий способ исполнения. Возможно, что в дальнейшем появятся суперскалярные VLIW-процессоры, которые тем самым приобретут, если так можно выразиться, «параллелизм в квадрате» — объединение явного статического параллелизма с неявным динамическим. Но на сегодняшнем этапе развития процессоров нет видимых способов совмещать статическое и динамическое переупорядочивание. Именно поэтому Itanium/Itanium2 сейчас следует рассматривать не столько в контексте сравнения VLIW «против» CISC (и тем более не VLIW «против» O3E), а скорее как «синхронный VLIW» vs «асинхронный (Out-Of-Order) RISC». Ну, и не стоит забывать, что альянс Intel-HP придумали для своей архитектуры отдельное название — EPIC, т.е. явный параллелизм.

Несмотря на то, что архитектура VLIW появилась еще на заре компьютерной индустрии (Тьюринг разработал VLIW-компьютер еще в 1946 году), она до сих пор не имела коммерческого успеха. Теперь Intel воплотила некоторые идеи VLIW в линейке процессоров Itanium. Но значительного повышения производительности и скорости вычислений в системах на базе этих процессоров по отношению к существующим классическим «RISC-inside CISC-outside» архитектурам можно добиться лишь путем переноса интеллектуальных функций из аппаратного обеспечения в программное (компилятор). Таким образом, успех Itanium/Itanium2 определяется в основном программными средствами — именно в этом и состоит проблема. Причем довольно сдержанное отношение индустрии к сравнительно давно существующему Itanium только подтвердило факт ее наличия.

EPIC: явный параллелизм команд

Концепция реализации параллелизма на уровне команд (Explicitly Parallel Instruction Computing) определяет новый тип архитектуры, способной конкурировать по масштабам влияния с RISC. Эта идеология направлена на то, чтобы упростить аппаратное обеспечение и, в то же время, извлечь как можно больше «скрытого параллелизма» на уровне команд, используя большую ширину «выдачи» команд (WIW -Wide Issue-Width) и длинные (глубокие) конвейеры с большой задержкой (DPL — Deep Pipeline-Latency), чем это можно сделать при реализации VLIW или суперскалярных стратегий. EPIC упрощает два ключевых момента, реализуемых во время выполнения. Во-первых, его принципы позволяют во время исполнения отказаться от проверки зависимостей между операциями, которые компилятор уже объявил как независимые. Во-вторых, данная архитектура позволяет отказаться от сложной логики внеочередного исполнения операций, полагаясь на порядок выдачи команд, определенный компилятором. Более того, EPIC совершенствует возможность компилятора статически генерировать планы выполнения за счет поддержки разного рода перемещений кода во время компиляции, которые были бы некорректными в последовательной архитектуре. Более ранние решения достигали этой цели главным образом за счет серьезного увеличения сложности аппаратного обеспечения, которое стало настолько значительным, что превратилась в препятствие, не позволяющее отрасли добиваться еще более высокой производительности. EPIC разработан именно для того, чтобы обеспечить более высокую степень параллелизма на уровне команд, поддерживая при этом приемлемую сложность аппаратного обеспечения.

Более высокая производительность достигается как за счет увеличения скорости передачи сигналов, так и благодаря увеличению плотности расположения функциональных устройств на кристалле. Зафиксировав рост этих двух составляющих, дальнейшего увеличения скорости выполнения программ можно добиться в первую очередь благодаря реализации определенного вида параллелизма. Так, параллелизм на уровне команд (ILP — Instruction-Level Parallelism) стал возможен благодаря созданию процессоров и методик компиляции, которые ускоряют работу за счет параллельного выполнения отдельных RISC-операций. Системы на базе ILP используют программы, написанные на традиционных языках высокого уровня, для последовательных процессоров, а обнаружение «скрытого параллелизма» автоматически выполняется благодаря применению соответствующей компиляторной технологии и аппаратного обеспечения.

Тот факт, что эти методики не требуют от прикладных программистов дополнительных усилий, имеет крайне важное значение, поскольку данное решение резко отличается от традиционного микропроцессорного параллелизма, который предполагает, что программисты должны переписывать свои приложения. Параллельная обработка на уровне команд является единственным надежным подходом, позволяющим добиться увеличения производительности без фундаментальной переработки приложения.

Суперскалярные процессоры — это реализации ILP-процессора для последовательных архитектур, программа для которых не должна передавать и, фактически, не может передавать точную информацию о параллелизме. Поскольку программа не содержит точной информации о наличии ILP, задача обнаружения параллелизма должна решаться аппаратурой, которая, в свою очередь, должна создавать план действий для обнаружения «скрытого параллелизма». Процессоры VLIW представляют собой пример архитектуры, для которой программа предоставляет точную информацию о параллелизме — компилятор выявляет параллелизм в программе и сообщает аппаратному обеспечению какие операции не зависят друг от друга. Эта информация имеет важное значение для физического слоя, поскольку в этом случае он «знает» без дальнейших проверок какие операции можно начинать выполнять в одном и том же такте. Архитектура EPIC — это эволюция архитектуры VLIW, которая абсорбировала в себе многие концепции суперскалярной архитектуры, хотя и в форме, адаптированной к EPIC. По сути — это «идеология», определяющая, как создавать ILP-процессоры, а также набор характеристик архитектуры, которые поддерживают данную основу. В таком смысле EPIC похож на RISC: определяющий класс архитектур, подчиняющихся общим основным принципам. Точно также, как существует множество различных архитектур наборов команд (ISA) для RISC, может существовать и больше одной ISA для EPIC. В зависимости от того, какие из характеристик EPIC использует архитектура EPIC ISA, она может быть оптимизирована для различных приложений — например, для систем общего назначение или встроенных устройств. Первым примером коммерческой EPIC ISA стала архитектура IA-64.

Код для суперскалярных процессоров содержит последовательность команд, которая порождает корректный результат, если выполняется в установленном порядке. Код указывает последовательный алгоритм и, за исключением того, что он использует конкретный набор команд, не представляет себе точно природу аппаратного обеспечения, на котором он будет работать или точный временной порядок, в котором будут выполняться команды. В отличие от программ для суперскалярных процессоров, код VLIW предлагает точный план (POE — Plan Of Execution, схема исполнения создается статически во время компиляции) того, как процессор будет выполнять программу. Код точно указывает когда будет выполнена каждая операция, какие функциональные устройства будут работать и какие регистры будут содержать операнды. Компилятор VLIW создает такой план выполнения, имея полное представление о самом процессоре, чтобы добиться требуемой записи исполнения (ROE — Record Of Execution) — последовательности событий, которые действительно происходят во время работы программы. Компилятор передает POE (через архитектуру набора команд, которая точно описывает параллелизм) аппаратному обеспечению, которое, в свою очередь, выполняет указанный план. Этот план позволяет VLIW использовать относительно простое аппаратное обеспечение, способное добиться высокого уровня ILP. В отличие от VLIW, суперскалярная аппаратура динамически строит POE на основе последовательного кода. Хотя такой подход и увеличивает сложность физической реализации, суперскалярный процессор создает план, используя преимущества тех факторов, которые могут быть определены только во время выполнения.

Одна из целей, которые ставили перед собой при создании EPIC, состояла в том, чтобы сохранить реализованный во VLIW принцип статического создания POE, но и в то же время обогатить его возможностями, аналогичными возможностям суперскалярного процессора, позволяющими новой архитектуре лучше учитывать динамические факторы, традиционно ограничивающие параллелизм, свойственный VLIW. Чтобы добиться этих целей, «идеология» EPIC была построена на некоторых основных принципах.

Первый — это создание плана выполнения во время компиляции. EPIC возлагает нагрузку по созданию POE на компилятор. Хотя, в общем, архитектура и физическая реализация могут препятствовать компилятору в выполнении этой задачи, процессоры EPIC предоставляют функции, которые помогают компилятору создавать план выполнения. Во время исполнения поведение процессора EPIC с точки зрения компилятора должно быть предсказуемым и управляемым. Динамическое внеочередное исполнение команд может «запутать» компилятор так, что он не будет «понимать», как его решения повлияют на реальную запись выполнения, созданную процессором, поэтому ему необходимо уметь предсказывать действия процессора, что еще больше усложняет задачу. В данной ситуации предпочтителен процессор, четко исполняющий то, что ему указывает программа. Суть же создания плана во время компиляции состоит в переупорядочивании исходного последовательного кода так, чтобы использовать все преимущества параллелизма приложения и максимально эффективно тратить аппаратные ресурсы, минимизируя время выполнения. Без соответствующей поддержки архитектуры такое переупорядочивание может нарушить корректность программы. Таким образом, поскольку EPIC возлагает создание POE на компилятор, она должна обеспечивать еще и архитектурные возможности, поддерживающие интенсивное переупорядочивание кода во время компиляции.

Следующим принципом является использование компилятором вероятностных оценок. Компилятор EPIC сталкивается с серьезной проблемой при создании плана выполнения: информация определенного типа, которая существенно влияет на запись исполнения, становится известна только лишь в момент выполнения программы. Например, компилятор не может точно знать какая из ветвей после оператора перехода будет выполняться, когда запланированный код пройдет базовые блоки и какой из путей графа будет выбран. Кроме того, обычно невозможно создать статический план, который одновременно оптимизирует все пути в программе. Неоднозначность также возникает и в тех случаях, когда компилятор не может решить, будут ли ссылки указывать на одно и то же место в памяти. Если да, то обращение к ним должно осуществляться последовательно; если нет, то их можно запланировать в произвольном порядке. При такой неоднозначности часто наиболее вероятен некий конкретный результат. Одним из важнейших принципов EPIC в данной ситуации является возможность разрешения компилятору оперировать вероятностными оценками — он создает и оптимизирует POE для наиболее вероятных случаев. Однако EPIC обеспечивает архитектурную поддержку, такую как спекулятивное выполнение по управлению и по данным (Control and Data Speculation), с тем, чтобы гарантировать корректность программы, даже если исходные предположения были не верны. Когда предположение оказывается неверным, совершенно очевидно падение производительности при выполнении программы. Такой эффект производительности иногда виден на плане программы, к примеру, в тех случаях, когда существует высоко оптимизированная программная область, а код исполняется в менее оптимизированной. Также падение производительности может возникнуть в моменты «остановки» (Stall), которые на плане программы не видны — определенные операции, подпадающие под наиболее вероятный и, следовательно, оптимизированный случай, выполняются при максимальной производительности, но приостанавливают процессор для того, чтобы гарантировать корректность, если возникнет менее вероятный, не оптимизированный случай.

После того, как создан план, компилятор передает его аппаратному обеспечению. Для этого ISA должен обладать возможностями достаточно богатыми, чтобы сообщить решения компилятора о том, когда инициировать каждую операцию и какие ресурсы использовать (в частности, должен существовать способ указать, какие операции инициируются одновременно). В качестве альтернативного решения компилятор мог бы создавать последовательную программу, которую процессор динамически реорганизует с тем, чтобы получить требуемую запись. Но в таком случае цель, сводимая к освобождению аппаратного обеспечения от динамического планирования, не достигается. При передаче POE аппаратному обеспечению крайне важно своевременно предоставить необходимую информацию. Примером этому может служить операция перехода, которая, в случае ее использования, требует, чтобы по адресу перехода команды выбирались с упреждением, заведомо до того, как будет инициирован сам переход. Вместо того, чтобы решение о том, когда это нужно сделать и какой адрес перехода отдавать на откуп аппаратному обеспечению, такая информация в соответствии с основными принципами EPIC передается аппаратному обеспечению точно и своевременно через код. Микроархитектура принимает и другие решения, не связанные напрямую с выполнением кода, но которые влияют на время выполнения. Один из таких примеров — управление иерархией кэш-памяти и соответствующие решения о том, какие данные нужны для поддержки иерархии, а какие следует заменить. Такие правила обычно предусматриваются алгоритмом функционирования контроллера кэша. EPIC расширяет принцип, утверждающий, что план выполнения компилятор создает так, чтобы тоже иметь возможность управлять этими механизмами микроархитектуры. Для этого обеспечиваются архитектурные возможности, позволяющие осуществлять программный контроль механизмами, которыми обычно управляет микроархитектура.

Аппаратно-программный комплекс VLIW

Архитектура VLIW представляет собой одну из реализаций концепции внутреннего параллелизма в микропроцессорах. Их быстродействие можно повысить двумя способами: увеличив либо тактовую частоту, либо количество операций, выполняемых за один такт. В первом случае требуется применение «быстрых» технологий (например, использование арсенида галлия вместо кремния) и таких архитектурных решений, как глубинная конвейеризация (конвейеризация в пределах одного такта, когда в каждый момент времени задействованы все логические блоки кристалла, а не отдельные его части). Для увеличения количества выполняемых за один цикл операций необходимо на одном чипе разместить множество функциональных модулей обработки и обеспечить надежное параллельное исполнение машинных инструкций, что дает возможность включить в работу все модули одновременно. Надежность в таком контексте означает, что результаты вычислений будут правильными. Для примера рассмотрим два выражения, которые связаны друг с другом следующим образом: А=В+С и В=D+Е. Значение переменной А будет разным в зависимости от порядка, в котором вычисляются эти выражения (сначала А, а потом В, или наоборот), но ведь в программе подразумевается только одно определенное значение. И если теперь вычислить эти выражения параллельно, то на правильный результат можно рассчитывать лишь с определенной вероятностью, а не гарантировано.

Планирование порядка вычислений — довольно трудная задача, которую приходится решать при проектировании современного процессора. В суперскалярных архитектурах для распознавания зависимостей между машинными инструкциями применяется специальное довольно сложное аппаратное решение (например, в P6- и post-P6-архитектуре от Intel для этого используется буфер переупорядочивания инструкций — ReOrder Buffer, ROB). Однако размеры такого аппаратного планировщика при увеличении количества функциональных модулей обработки возрастают в геометрической прогрессии, что, в конце концов, может занять весь кристалл процессора. Поэтому суперскалярные проекты остановились на отметке 5-6 обрабатываемых за цикл инструкций. На самом же деле, текущие реализации VLIW тоже далеко не всегда могут похвастаться 100% заполнением пакетов — реальная загрузка около 6-7 команд в такте — примерно столько же, сколько и лидеры среди RISC-процессоров. При другом подходе можно передать все планирование программному обеспечению, как это делается в конструкциях с VLIW. «Умный» компилятор должен выискать в программе все инструкции, которые являются совершенно независимыми, собрать их вместе в очень длинные строки (длинные инструкции) и затем отправить на одновременное исполнение функциональными модулями, количество которых, как минимум, не меньше, чем количество операций в такой длинной команде. Очень длинные инструкции (VLIW) обычно имеют размер 256-1024 bit, однако, бывает и меньше. Сам же размер полей, кодирующих операции для каждого функционального модуля, в такой метаинструкции намного меньше.

Логический слой VLIW-процессора

Эта гипотетическая инструкция имеет восемь операционных полей, каждое из которых выполняет традиционную трехоперандную RISC-подобную инструкцию типа <регистр приемника> = <регистр источника 1> — <операция> — <регистр источника 2> (типа классической команды MOV AX BX) и может непосредственно управлять специфическим функциональным блоком при минимальном декодировании.

Для большей конкретности рассмотрим кратко IA-64 как один из примеров воплощения VLIW. Со временем эта архитектура способна вытеснить x86 (IA-32) не только на рынке, но вообще как класс, хотя это уже удел далекого будущего. Тем не менее, необходимость разработки для IA-64 весьма сложных компиляторов и трудности с созданием оптимизированных машинных кодов может вызвать дефицит специалистов, работающих на ассемблере IA-64, особенно на начальных этапах, как самых сложных.

Наиболее кардинальным нововведением IA-64 по сравнению с RISC является явный параллелизм команд (EPIC), вносящий некоторые элементы, напоминающие архитектуру сверхдлинного командного слова, которые назвали связками (bundle). Так, в обеих архитектурах явный параллелизм представлен уже на уровне команд, управляющих одновременной работой функциональных исполнительных устройств (или функциональных модулей, или просто функциональных устройств, ФУ).

Шаблон указывает какого непосредственно типа команды находятся в слотах связки. В общем случае однотипные команды могут выполняться в более чем одном типе функциональных устройств. Шаблоном задаются так называемые остановки, определяющие слот, после начала выполнения команд которого инструкции последующих полей должны ждать завершения. Порядок слотов в связке (более важные справа) отвечает и порядку байт (Little Endian), однако данные в памяти могут располагаться и в режиме Big Endian (более важные слева), который устанавливается специальным битом в регистре маски пользователя.

Вращение регистров является в некотором роде частным случаем переименования регистров, применяемого во многих современных суперскалярных процессорах с внеочередным спекулятивным («умозрительным») выполнением команд. В отличие от них, вращение регистров в IA-64 управляется программно. Использование этого механизма в IA-64 позволяет избежать накладных расходов, связанных с сохранением/восстановлением большого числа регистров при вызовах подпрограмм и возвратах из них, однако статические регистры при необходимости все-таки приходится сохранять и восстанавливать, явно кодируя соответствующие команды.

К слову, система команд IA-64 довольно уникальна. Cреди принципиальных особенностей следует отдельно отметить спекулятивное выполнение команд и применение предикатов — именно это подмножество и определяет исключительность IA-64. Все подобные команды можно подразделить на команды работы со стеком регистров, целочисленные команды, команды сравнения и работы с предикатами, команды доступа в память, команды перехода, мультимедийные команды, команды пересылок между регистрами, «разные» (операции над строками и подсчет числа единиц в слове) и команды работы с плавающей запятой.

Аппаратная реализация VLIW-процессора очень проста: несколько небольших функциональных модулей (сложения, умножения, ветвления и т.д.), подключенных к шине процессора, и несколько регистров и блоков кэш-памяти. VLIW-архитектура представляет интерес для полупроводниковой промышленности по двум причинам. Первая — теперь на кристалле больше места может быть отведено для блоков обработки, а не, скажем, для блока предсказания переходов. Вторая причина — VLIW-процессор может быть высокоскоростным, так как предельная скорость обработки определяется только внутренними особенностями самих функциональных модулей. Привлекает и то, что VLIW при определенных условиях может реализовать старые CISC-инструкции эффективнее RISC. Это потому, что программирование VLIW-процессора очень напоминает написание микрокода (исключительно низкоуровневый язык, позволяющий всесторонне программировать физический слой, синхронизируя работу логических вентилей с шинами обмена данными и управляя передачей информации между функциональными модулями).

В те времена, когда память для ПК была дорогостоящей, программисты экономили ее, прибегая к сложным инструкциям процессора x86 типа STOS и LODS (косвенная запись/чтение в/из памяти). CISC реализует такие инструкции, как микропрограммы, зашитые в постоянную память (ROM) и выполняемые процессором. Архитектура RISC вообще исключает использование микрокода, реализуя инструкции чисто аппаратным путем — фактически, инструкции RISC-процессора почти аналогичны микрокоду, используемому в CISC. VLIW делает по-другому — изымает процедуру генерирования микрокода из процессора (да и вообще стадии исполнения) и переносит его в компилятор, на этап создания исполняемого кода. В результате эмуляция инструкций процессора x86, таких как STOS, осуществляется очень эффективно, поскольку процессор получает для исполнения уже готовые макросы. Но вместе с тем, это порождает и некоторые трудности, поскольку написание достаточно эффективного микрокода — невероятно трудоемкий процесс. Архитектуре VLIW может обеспечить жизнеспособность только «умный» компилятор, который возьмет эту работу на себя. Именно это обстоятельство ограничивает использование вычислительных машин с архитектурой VLIW: пока они нашли свое применение в основном в векторных (для научных расчетов) и сигнальных процессорах.

Принцип действия VLIW-компилятора

Вновь вспыхнувший в последнее время интерес к VLIW как к архитектуре, которую можно использовать для реализации вычислений общего назначения, дал существенный толчок развитию техники VLIW-компиляции. Такой компилятор упаковывает группы независимых операций в очень длинные слова инструкций таким способом, чтобы обеспечить быстрый запуск и более эффективное их исполнение функциональными модулями. Компилятор сначала обнаруживает все зависимости между данными, а затем определяет, как их развязать. Чаще всего это делается путем переупорядочивания всей программы — разные ее блоки перемещаются с одного места в другое. Данный подход отличается от применяемого в суперскалярном процессоре, который для определения зависимостей использует специальное аппаратное решение прямо во время выполнения приложения (оптимизирующие компиляторы, безусловно, улучшают работу суперскалярного процессора, но не делают его «привязанным» к ним). Большинство суперскалярных процессоров может обнаружить зависимости и планировать параллельное исполнение только внутри базовых программных блоков (группа последовательных операторов программы, не содержащих внутри себя останова или логического ветвления, допустимых только в конце). Некоторые переупорядочивающие системы положили начало расширению области сканирования, не ограничивая ее базовыми блоками. Для обеспечения большего параллелизма VLIW-компьютеры должны наблюдать за операциями из разных базовых блоков, чтобы поместить эти операции в одну и ту же длинную инструкцию (их «область обзора» должна быть шире, чем у суперскалярных процессоров) — это обеспечивается путем прокладки «маршрута» по всей программе (трассировка). Трассировка — наиболее оптимальный для некоторого набора исходных данных маршрут по программе (для обеспечения правильного результата гарантируется не пересечение этих данных), т.е. маршрут, который «проходит» по участкам, пригодным для параллельного выполнения (эти участки формируются, кроме всего прочего, и путем переноса кода из других мест программы), после чего остается упаковать их в длинные инструкции и передать на выполнение. Планировщик вычислений осуществляет оптимизацию на уровне всей программы, а не ее отдельных базовых блоков. Для VLIW, так же как и для RISC, ветвления в программе являются «врагом», препятствующим эффективному ее выполнению. В то время как RISC для прогнозирования ветвлений использует аппаратное решение, VLIW оставляет это компилятору. Сам компилятор использует информацию, собранную им путем профилирования программы, хотя у будущих VLIW-процессоров предполагается небольшое аппаратное расширение, обеспечивающее сбор для компилятора статистических данных непосредственно во время выполнения программы, что принципиально важно при циклической работе с переменным набором. Компилятор прогнозирует наиболее подходящий маршрут и планирует прохождение, рассматривая его как один большой базовый блок, затем повторяет этот процесс для всех других возникших после этого программных веток, и так до самого конца программы. Он также умеет делать при анализе кода и другие «интеллектуальные шаги», такие как развертывание программного цикла и IF-преобразование, в процессе которого временно удаляются все логические переходы из секции, подвергающейся трассировке. Там, где RISC может только просмотреть код вперед на предмет ветвлений, VLIW-компилятор перемещает его с одного места в другое до обнаруженного ветвления (согласно трассировке), но предусматривает при необходимости возможность отката назад, к предыдущему программному состоянию. Формально ничего не мешает это же сделать и RISC процессору, просто соотношение «цена/эффективность» оказывается слишком высоким. Соответствующее аппаратное обеспечение, добавленное к VLIW-процессору, может оказать определенную поддержку компилятору. Например, операции, имеющие по несколько ветвлений, могут входить в одну длинную инструкцию и, следовательно, выполняться за один машинный такт. Поэтому выполнение условных операций, которые зависят от предыдущих результатов, может быть реализовано программным способом, а не аппаратным. Цена, которую приходится платить за увеличение быстродействия VLIW-процессора, намного меньше стоимости компиляции — именно поэтому основные расходы приходятся на сами компиляторы.

VLIW: обратная сторона медали

Тем не менее, при реализации архитектуры VLIW возникают и другие серьезные проблемы. VLIW-компилятор должен в деталях «знать» внутренние особенности архитектуры процессора, опускаясь до устройства самих функциональных блоков. Как следствие, при выпуске новой версии VLIW-процессора с большим количеством обрабатывающих модулей (или даже с тем же количеством, но другим быстродействием) все старое программное обеспечение может потребовать полной перекомпиляции. Производители VLIW-процессоров обрекли себя на, как минимум, не уменьшение ширины пакета, хотя бы ради того, чтобы «старые» программы могли гарантированно исполнятся на новых устройствах. Например, на настоящее время существуют пакеты по 8 команд, а следующая версия не может иметь в реализации всего шесть функциональных устройств даже ради двух-трех- кратного прироста по частоте. Кроме того, что программа, скомпилированная для восьмиканального VLIW, не сможет без специальных дорогостоящих (и в плане сложности, и в плане производительности) аппаратных решений исполняться на шестиканальной архитектуре, придется радикально переписывать и компилятор. С этой точки зрения представляется разумным использование Intel трехкомандного слова в системе IA64 — такое, на первый взгляд, неудобное ограничение позволяет в будущем довольно свободно варьировать число исполнительных устройств в процессорах IA64. И если при переходе с 386 на процессор 486 производить перекомпиляцию имеющегося ПО было совершенно ненужно, то теперь придется. В качестве одного из возможных компромиссных решений предлагается разделить процесс компиляции на две стадии. Все программное обеспечение должно готовиться в аппаратно-независимом формате с использованием промежуточного кода, который окончательно транслируется в машинно-зависимый код только в процессе установки на оборудовании конечного пользователя. Пример такого подхода демонстрирует фонд OSF со своим архитектурно-независимым форматом ANDF (Architecture-Neutral Distribution Format). Но кроссплатформенное программное обеспечение пока что не оправдывает когда-то возлагавшихся на него радужных надежд. Во-первых, оно все равно требует наличия портов, которые «объясняют» компилятору в каждом конкретном случае что следует делать при компиляции данной программы именно на этой платформе (и даже именно на этой ОС). Во-вторых, кроссплатформенное ПО пока отнюдь не является «Speed Demon», а даже наоборот, как правило работает медленнее, чем написанное под конкретную платформу аналогичного класса приложения.

Другая трудность — это по своей сути статическая природа оптимизации, которую обеспечивает VLIW-компилятор. Трудно предугадать как, например, поведет себя программа, когда столкнется во время компиляции с непредусмотренными динамическими ситуациями, такими как ожидание ввода/вывода. Архитектура VLIW возникла в ответ на требования со стороны научно-технических организаций, где при вычислениях особенно необходимо большое быстродействие процессора, но для объектно-ориентированных и управляемых по событиям программ она менее подходит, а ведь именно такие приложения составляют сейчас большинство в сфере Информационных Технологий. Остается труднопредполагаемой проверка, что компилятор выполняет такие сложные преобразования надежно и правильно. Напротив, Out-Of-Order RISC-процессоры вполне способны «адаптироваться» под конкретную ситуацию самым выгодным образом.

Сейчас уже стало очевидным, что разработчики современных быстродействующих VLIW-процессоров начинают отходить от своей первоначальной затеи с чистой VLIW-архитектурой. Intel, по крайней мере, сохранила семейству Itanium возможность исполнять классический x86-код, правда, судя по всему, удалось ей это сделать ценой колоссальных потерь производительности при работе процессора в таком режиме. Можно предположить, что процессорный гигант сдал бастион «чистого VLIW» под нажимом гигантов ПО. Однако решение сложной задачи обеспечения взаимодействия аппаратного и программного обеспечения в архитектуре VLIW требует серьезных предварительных исследований. Увы, на данный момент теоретические изыскания в области алгоритмов автоматического распараллеливания программ все еще не могут похвастаться большим количеством достижений: как правило, если требуется грамотно распараллелить программу (к примеру, для введения в нее SMP-оптимизированных участков), делается это по старинке — «руками», причем руками весьма и весьма квалифицированных программистов. К тому же давно известен немалый список задач, поддающихся распараллеливанию с громадными усилиями или даже не поддающихся вообще.

Как пример, можно вспомнить знаменитый Crusoe от Transmeta. Принцип его работы фактически состоит в динамической перекомпиляции под VLIW-архитектуру уже скомпилированного x86 кода. Однако, если даже в создании эффективных VLIW-компиляторов для языков высокого уровня разработчики сталкиваются с такими большими сложностями, то что можно сказать о «компиляторе» весьма хаотичного и непредсказуемого машинного кода x86, тем более, что он зачастую опять-таки оптимизирован при компиляции, но в расчете на совсем другие архитектурные особенности.

Реально же Crusoe применяется только в режиме эмуляции х86, хотя принципиальных ограничений на эмуляцию любого другого кода нет. При этом все программы и сама операционная система работают поверх низкоуровневого программного обеспечения, называемого морфингом кода (Code Morphing) и ответственного за трансляцию х86-кодов в связки, имеющие размер 128bit. Crusoe использует также собственную терминологию, тонко определяющую уровень логического слоя архитектуры, в которой связки называются молекулами (Molecule), а 32bit подкоманды, располагаемые в связке, — атомами (Atom). Каждая молекула содержит два или четыре атома. Для совместимости с форматом команд, если при двоичной трансляции не удается заполнить все «атомные» слоты молекулы, в незаполненные поля должна вставляется пустая подкоманда NOP, указывающая на отсутствие операции (No OPeration). В результате, благодаря применению двух типов молекул, в каждой из них оказывается не более одной NOP. Всего же за такт могут исполняться до четырех подкоманд VLIW. Среди важных архитектурных особенностей VLIW-ядра Crusoe выделяются относительно короткие конвейеры: целочисленный на семь стадий и на десять с плавающей запятой. Теоретически данный процессор может применяться для эмуляции различных архитектур, однако ряд особенностей его микроархитектуры нацелен на эффективную эмуляцию именно х86 кода. Принципиально важным отличием является практически отсутствие потерь производительности в условиях примерно равной частоты процессоров при х86-эмуляции. Сначала устройство декодирует х86-последовательность в режиме интерпретации «байт за байтом», однако если код выполняется несколько раз, то механизм морфинга транслирует его в оптимальную последовательность молекул, а результат трансляции кэшируется для повторного использования.

Можно сказать, что Transmeta попыталась не то, что опередить время, а даже «перескочить через голову» уже и так опередившей время технологии. В принципе же то, что сделала Transmeta — просто фантастическое техническое достижение. По сути дела, продемонстрирована работающая в реальном времени технология динамической компиляции кроссплатформенного ПО. Если так работает система, переводящая «на лету» х86 код во внутреннее представление, то остается только догадываться как бы она работала с первоначально ориентированной для нее программой. Таким образом, бинарная совместимость возможна и довольно эффективна.

С другой стороны, даже сам Гордон Мур уже заявил, что рост частоты процессоров в ближайшее время скорее всего перестанет подчиняться сформулированному им эмпирическому правилу, и существенно замедлится. В этой ситуации производительность классических систем рискует довольно скоро упереться в «тупик» физических ограничений, что в еще большей степени подхлестнет развитие альтернативных повышению частоты способов увеличения быстродействия, одним из которых является разработка принципиально новых и хорошо распараллеливающихся алгоритмов, что и позволит проявить себя VLIW во всей красе.

Вместо заключения

За последние годы сравнение достоинств VLIW и суперскалярных архитектур было основной темой в дискуссиях специалистов по реализации параллелизма на уровне команд (ILP). Сторонники той и другой концепции сводят это обсуждение к противопоставлению простоты и ограниченных возможностей VLIW, и динамическим возможностям суперскалярных систем. Но, как уже было замечено ранее, такое сравнение в корне неверно. Совершенно очевидно, что оба подхода имеют свои достоинства и говорить об их альтернативности не уместно. Создание плана выполнения во время компиляции существенно для обеспечения высокой степени распараллеливания на уровне команд, даже для суперскалярного процессора. Также ясно и то, что во время компиляции существует неоднозначность, которую можно разрешить только во время исполнения, и для решения этой задачи процессор требует наличия динамических механизмов. Сторонники EPIC согласны с обеими этими позициями — различие только в том, что EPIC предоставляет эти механизмы на уровне архитектуры так, что компилятор может управлять такими динамическими механизмами, применяя их выборочно где это возможно. Столь широкие возможности помогают компилятору использовать правила управления этими механизмами более оптимально, чем это позволяет аппаратура.

Основные принципы EPIC, наряду с возможностями самой архитектуры, которая их поддерживает, обеспечивают средства определения ILP-архитектур и процессоров, позволяющих добиться более высокой степени параллелизма на уровне команд при меньшей сложности аппаратуры в самых разных прикладных областях. Говоря более конкретно, IA-64 — это пример того, как принципы EPIC могут применяться к вычислительными системам общего назначения — области, где совместимость объектного кода имеет критически важное значение. Однако есть уверенность, что со временем EPIC будет играть столь же важную роль и на рынке высокопроизводительных встроенных систем. В этой области более жесткие требования к соотношению цена/производительность и при этом более низкие требования к совместимости на уровне объектных модулей, что заставляет использовать более «гибкие» архитектуры. Понимая данную ситуацию, HP Labs начала реализацию исследовательского проекта PICO (Program In, Chip Out), в рамках которого уже разработан прототип, где наряду с другими возможностями на основе встроенных приложений, написанных на стандартном языке С, можно автоматически проектировать архитектуру и микроархитектуру процессора EPIC, адаптированного к конкретной задаче. Таким образом, EPIC дает новые надежды на устойчивый рост производительности микропроцессоров общего назначения, выполняя конкретные приложения без кардинального переписывания кода.

Главной проблемой VLIW-процессоров по-видимому является противоречие между, по большей части, последовательной логикой приложений и природой подавляющего большинства вычислительных алгоритмов, с одной стороны, и параллельной природой исполнения VLIW-процессора — с другой. Ограничение числа функциональных устройств в классических процессорах вызвано скорее всего не только и не столько невозможностью организовать эффективное внеочередное исполнение, а просто-напросто ограниченным количеством способных исполняться независимо команд.

Хотя, если не ограничивать оптимизатор жесткими временными рамками (как в классических суперскалярных процессорах), то, наверное, на некоторых алгоритмах можно добиться достаточно плотной упаковки инструкций, но только на некоторых. Примером, в частности, могут выступать программы, управляемые по событию, с постоянно меняющимся набором данных, которые статической оптимизации поддаются с огромным трудом. Вполне можно предположить ситуацию, когда изменение набора данных приведет к фатальному падению производительности, например, при работе с базами данных. Способ предотвратить такое развитие событий видится такой — при компиляции программы «пройти» все ветки алгоритма во всех возможных сочетаниях данных, сгенерировав оптимальный код для каждой возможной ситуации. Но, очевидно, что такое решение повлечет за собой вполне объяснимый рост размеров скомпилированного приложения, а необходимость подгружать из ОЗУ на исполнение различные (по ситуации) куски оптимального кода понятным образом увеличит нагрузку и на подсистему памяти. В этой связи логичным представляется рост размеров кэш-памяти, например, у настоящего Itanium2 по сравнению с Itanium — и это несмотря на увеличенную в несколько раз пропускную способность шины данных.

Определенный интерес представляет собой теоретическая возможность упаковки в одну связку инструкций, принадлежащих, например, различным ветвям алгоритма с целью одновременного их исполнения с выбором в последствии актуального результата. Такой способ может исключить саму идею предсказания ветвлений, при этом оказавшись сравнительно упрощенным с точки зрения производительности, но размер кода и нагрузка на память вырастут несоизмеримо. С другой стороны, если ветвление не бинарное а больше, то в таком случае увеличится и нагрузка на устройства декодирования команд — при возросшей плотности подгрузки инструкций (обе ветки вместо одной) могут возникнуть, например, ситуации конкуренции за максимально возможную пропускную способность основной шины (FSB — Front Side Bus) и/или кэш-памяти (BSB — Back Side Bus).

Нельзя не отметить тот факт, что предварительное планирование последовательности операций в большем числе случаев, чем для классических процессоров, позволит максимально полно использовать реальную пропускную способность шины данных. Но столь высокая и прогнозируемая эффективность использования интерфейса требует, с другой стороны, принципиально нового подхода к построению системы.

Самым же «интересным» (и опасным для концепции) аспектом развития VLIW-архитектур можно считать проблему статической оптимизации кода в сочетании с возможными изменениями внутренней архитектуры процессоров. Вполне очевидно, что оптимизированная для одного устройства программа может оказаться совершенно непригодной (малоэффективной) для работы на следующем поколении процессоров. Тем не менее, существует метод, позволяющий изящно обойти данную проблему. Суть идеи состоит в том, что распространяемый «дистрибутив» приложения содержит не готовый к исполнению код, и не исходные тексты (по идее OSF), а результат некоторого промежуточного этапа компиляции: с описанными зависимостями, формализованным описанием процессов, развернутыми циклами — в общем содержит именно то, что традиционно считается самой сложной частью работы компилятора и, собственно, определяет качество его работы. Инсталлятор в процессе установки программы вызывает некий специфический для данного процессора компилятор, преобразующий этот промежуточный код в исполняемый — причем, оптимальным для данного процессора (и более того — конфигурации) образом. Развивая данную мысль, можно предложить вариант составления финального компилятора (опций его работы) на основании библиотек, описывающих используемые подсистемы. Итогом такого подхода может стать, во-первых, «выжимание» максимально возможной производительности из каждой конкретной конфигурации компьютера, а, во-вторых, может повлечь за собой исчезновение понятия «аппаратно-программная платформа». Любая операционная система сможет быть установлена на любой процессор, если только есть набор требуемых драйверов (описаний). Однако это слишком идеальная схема.

Альтернативой предложенным вариантам можно назвать Crusoe-подобную систему с динамической компиляцией приложений, поставляемых в виде промежуточного кода непосредственно во время исполнения. С одной стороны, очевидно, что производительность из-за дополнительной нагрузки в виде динамической компиляции будет ниже, а с другой — простота такого решения и его очевидно большая гибкость (например, динамический транслятор может учитывать поведение одновременно исполняющихся в системе приложений) делают такой способ достаточно привлекательным. Опять-таки, подобный динамический компилятор вполне может (и даже должен) руководствоваться во время работы информацией об имеющемся оборудовании.

В статье использовались материалы, опубликованные на сайте издательства Открытые системы
Огромная благодарность за неоценимую помощь в подготовке и обработке материала:
Виктору Картунову aka matik
Олегу Бессонову aka bess

Очень длинное командное слово (VLIW ) относится к архитектурам набора команд разработан для использования параллелизма на уровне команд (ILP). В то время как обычные центральные процессоры (ЦП, процессор) в основном позволяют программам определять инструкции для выполнения только в последовательности, процессор VLIW позволяет программам явно указывать инструкции для выполнения в параллельном. Эта конструкция предназначена для обеспечения более высокой производительности без сложности, присущей некоторым другим конструкциям.

Содержание

• 1 Обзор
• 2 Мотивация
• 3 Дизайн
• 4 История
• 5 Реализации
• 6 Обратная совместимость
• 7 См. Также
• 8 Ссылки
• 9 Внешние ссылки

Обзор

Традиционные средства повышения производительности в процессорах включают разделение инструкций на подшаги, чтобы инструкции могли выполняться частично одновременно (так называемая конвейерная обработка), отправка отдельных инструкций для независимого выполнения в различные части процессора (суперскалярная архитектуры) и даже выполнение инструкций в порядке, отличном от программы (выполнение вне очереди ). Все эти методы усложняют оборудование (более крупные схемы, более высокая стоимость и потребление энергии), потому что процессор должен принимать все внутренние решения, чтобы эти методы работали. Напротив, метод VLIW зависит от программ, принимающих все решения относительно того, какие инструкции выполнять одновременно и как разрешать конфликты. На практике это означает, что компилятор (программное обеспечение, используемое для создания конечных программ) становится намного сложнее, но аппаратное обеспечение проще, чем во многих других средствах параллелизма.

Мотивация

Процессор, который выполняет каждую инструкцию одну за другой (т. Е. Не конвейерная скалярная архитектура), может неэффективно использовать ресурсы процессора, что может привести к снижению производительности. Производительность может быть улучшена путем одновременного выполнения различных подэтапов последовательных инструкций (так называемая конвейерная обработка) или даже выполнения нескольких инструкций полностью одновременно, как в суперскалярных архитектурах. Дальнейшее улучшение может быть достигнуто путем выполнения инструкций в порядке, отличном от того, в котором они встречаются в программе, что называется выполнение вне очереди.

Все эти три метода повышают сложность оборудования. Перед тем, как выполнять какие-либо операции параллельно, процессор должен проверить, что инструкции не имеют взаимозависимостей. Например, если результат первой инструкции используется как вход второй инструкции, то они не могут выполняться одновременно, а вторая инструкция не может выполняться раньше первой. Современные вышедшие из строя процессоры увеличили аппаратные ресурсы, которые планируют инструкции и определяют взаимозависимости.

Напротив, VLIW выполняет операции параллельно на основе фиксированного расписания, определяемого, когда программы компилируются. Поскольку определение порядка выполнения операций (включая то, какие операции могут выполняться одновременно) обрабатывается компилятором, процессору не требуется аппаратное обеспечение планирования, которое требуется для трех описанных выше методов. Таким образом, процессоры VLIW предлагают больше вычислений с меньшей аппаратной сложностью (но с большей сложностью компилятора), чем большинство суперскалярных процессоров.

Дизайн

В суперскалярных проектах количество исполнительных единиц невидимо для набора команд. Каждая инструкция кодирует только одну операцию. Для большинства суперскалярных схем ширина инструкции составляет 32 бита или меньше.

Напротив, одна инструкция VLIW кодирует несколько операций, по меньшей мере, одну операцию для каждой исполнительной единицы устройства. Например, если устройство VLIW имеет пять исполнительных блоков, то инструкция VLIW для устройства имеет пять полей операций, каждое поле указывает, какая операция должна быть выполнена на соответствующем исполнительном блоке. Чтобы приспособиться к этим полям операций, инструкции VLIW обычно имеют ширину не менее 64 бит и намного шире на некоторых архитектурах.

Например, ниже приводится инструкция для однокристального компьютера с архитектурой Super Harvard (SHARC). За один цикл он выполняет умножение с плавающей запятой, сложение с плавающей запятой и две загрузки с автоинкрементом. Все это умещается в одной 48-битной инструкции:

f12 = f0 * f4, f8 = f8 + f12, f0 = dm (i0, m3), f4 = pm (i8, m9);

Начиная с самого раннего В дни компьютерной архитектуры некоторые процессоры добавили несколько арифметических логических блоков (ALU) для параллельной работы. Суперскалярные ЦП используют оборудование, чтобы решить, какие операции могут выполняться параллельно во время выполнения, в то время как ЦП VLIW используют программное обеспечение (компилятор), чтобы заранее решить, какие операции могут выполняться параллельно. Поскольку сложность планирования команд переносится в компилятор, сложность аппаратного обеспечения может быть существенно снижена.

Аналогичная проблема возникает, когда результат распараллеливаемой инструкции используется в качестве входных данных для перехода. Большинство современных процессоров предполагают, какая ветвь будет выбрана еще до завершения вычислений, чтобы они могли загрузить инструкции для ветки или (в некоторых архитектурах) даже начать вычислять их предположительно. Если ЦП ошибается, все эти инструкции и их контекст необходимо очистить и загрузить правильные, что требует времени.

Это привело к усложнению логики диспетчеризации инструкций , которая пытается правильно угадать, и простота первоначальной конструкции вычислений с сокращенным набором команд (RISC) была эрозия. В VLIW отсутствует эта логика, поэтому не хватает энергии, возможных дефектов конструкции и других негативных аспектов.

В VLIW компилятор использует эвристику или информацию профиля, чтобы угадать направление ветвления. Это позволяет ему спекулятивно перемещать и заранее планировать операции до перехода в ветвь, отдавая предпочтение наиболее вероятному пути, который он ожидает через ветвь. Если ветвление идет неожиданным путем, компилятор уже сгенерировал компенсирующий код, чтобы отбросить спекулятивные результаты, чтобы сохранить семантику программы.

Векторный процессор (одна инструкция, несколько данных (SIMD )) ядра могут быть объединены с архитектурой VLIW, например, в микропроцессоре Fujitsu FR-V, для дальнейшего увеличения пропускная способность и скорость.

История

Концепция архитектуры VLIW и термин VLIW были изобретены Джошем Фишером в его исследовательской группе в Йельский университет в начале 1980-х. Его первоначальная разработка планирования трассировки как метода компиляции для VLIW была разработана, когда он был аспирантом Нью-Йоркского университета. До VLIW понятие предварительного планирования исполнительных блоков и параллелизма на уровне инструкций в программном обеспечении было прочно закреплено в практике разработки горизонтального микрокода.

. Инновации Фишера включали разработку компилятора, который мог ориентироваться на горизонтальный микрокод из программы, написанные на обычном языке программирования . Он понял, что для получения хорошей производительности и целевой машины с широким выпуском потребуется найти параллелизм, выходящий за рамки обычного базового блока. Он также разработал методы выявления параллелизма за пределами базовых блоков. Планирование трассировки — такой метод, который включает в себя планирование наиболее вероятного пути основных блоков в первую очередь, вставку компенсирующего кода для работы со спекулятивными движениями, планирование второй наиболее вероятной трассы и так далее, пока расписание не будет завершено.

Вторым нововведением Фишера было представление о том, что целевая архитектура ЦП должна быть спроектирована так, чтобы быть разумной целью для компилятора; что компилятор и архитектура процессора VLIW должны иметь кодовую подпись. Частично это было вызвано трудностями, которые Фишер заметил в Йельском университете при компиляции для таких архитектур, как Floating Point Systems ‘FPS164, в которых была архитектура вычисления комплексного набора команд (CISC), которая отделяла инициацию команд от инструкции, которые сохранили результат, требовали очень сложных алгоритмов планирования. Фишер разработал набор принципов, характеризующих надлежащую конструкцию VLIW, таких как самодренирующиеся конвейеры, широкие многопортовые регистровые файлы и архитектуры памяти. Эти принципы облегчили компиляторам создание быстрого кода.

Первый компилятор VLIW был описан в докторской степени. диссертация Джона Эллиса под руководством Фишера. Компилятор получил название Bulldog в честь талисмана Йельского университета.

Фишер покинул Йель в 1984 году, чтобы основать стартап-компанию Multiflow вместе с соучредителями Джоном О’Доннеллом и Джоном Руттенбергом. Multiflow произвела серию TRACE VLIW мини-суперкомпьютеров, поставив свои первые машины в 1987 году. VLIW Multiflow мог выполнять 28 операций параллельно на одну команду. Система TRACE была реализована в виде сочетания средней интеграции (MSI), крупномасштабной интеграции (LSI) и очень крупномасштабной интеграции (VLSI), упакованных в шкафы, и эта технология устарела, поскольку она стала более рентабельной, если интегрировать все компоненты процессора (за исключением памяти) в один чип.

Multiflow было слишком рано, чтобы поймать следующую волну, когда архитектуры микросхем стали допускать многозадачные ЦП. Крупные полупроводниковые компании осознали ценность технологии Multiflow в этом контексте, поэтому компилятор и архитектура впоследствии были лицензированы для большинства этих фирм.

реализации

Cydrome была компанией, производившей числовые процессоры VLIW с использованием интегральных схем эмиттерной логики (ECL) в тот же период времени (конец 1980-х). Эта компания, как и Multiflow, потерпела крах через несколько лет.

Одним из лицензиатов технологии Multiflow является Hewlett-Packard, к которому Джош Фишер присоединился после прекращения деятельности Multiflow. Боб Рау, основатель Cydrome, также присоединился к HP после неудачи Cydrome. Эти двое руководили исследованиями компьютерной архитектуры в Hewlett-Packard в 1990-х годах.

Наряду с вышеуказанными системами, в то же время (1989–1990), Intel реализовала VLIW в Intel i860, своем первом 64-битном микропроцессоре и первом процессоре, реализовавшем VLIW. на одной микросхеме. Этот процессор мог работать как в простом режиме RISC, так и в режиме VLIW:

В начале 1990-х годов Intel представила микропроцессор i860 RISC. Этот простой чип имел два режима работы: скалярный режим и режим VLIW. В режиме VLIW процессор всегда выбирал две инструкции и предполагал, что одна была целочисленной инструкцией, а другая — с плавающей точкой.

Режим VLIW i860 широко использовался во встроенном цифровом сигнальном процессоре. (DSP), поскольку выполнение приложений и наборы данных были простыми, хорошо упорядоченными и предсказуемыми, что позволяло разработчикам в полной мере использовать преимущества параллельного выполнения, предоставляемые VLIW. В режиме VLIW i860 может поддерживать производительность с плавающей запятой в диапазоне 20-40 MFLOPS двойной точности; очень высокое значение для своего времени и для процессора, работающего на частоте 25-50 МГц.

В 1990-х годах Hewlett-Packard исследовала эту проблему как побочный эффект продолжающейся работы над семейством процессоров PA-RISC. Они обнаружили, что ЦП можно значительно упростить, удалив сложную логику диспетчеризации из ЦП и поместив ее в компилятор. Компиляторы того времени были намного сложнее, чем компиляторы 1980-х годов, поэтому добавленная сложность компилятора считалась небольшой стоимостью.

ЦП VLIW обычно состоят из нескольких RISC-подобных исполнительных блоков, которые работают независимо. Современные VLIW обычно имеют от четырех до восьми основных исполнительных единиц. Компиляторы генерируют начальные последовательности команд для ЦП VLIW примерно так же, как для традиционных ЦП, генерируя последовательность инструкций, подобных RISC. Компилятор анализирует этот код на предмет отношений зависимости и требований к ресурсам. Затем он планирует инструкции в соответствии с этими ограничениями. В этом процессе независимые инструкции могут планироваться параллельно. Поскольку VLIW обычно представляют инструкции, запланированные параллельно с более длинным командным словом, которое включает в себя отдельные инструкции, это приводит к гораздо более длинному коду операции (называемому очень длинным), чтобы указать, что выполняется в данном цикле.

Примеры современных ЦП VLIW включают медиапроцессоры TriMedia от NXP (ранее Philips Semiconductors), однокристальный компьютер с архитектурой Super Harvard (SHARC) от Analog Устройства, семейство цифровых сигнальных процессоров C6000 (DSP) от Texas Instruments, семейство ST200 от STMicroelectronics на основе архитектуры Lx ( разработан Паоло Фарабоски в лаборатории HP Джоша Фишера), а семейство MPPA Manycore — Калреем. Эти современные процессоры VLIW в основном успешны в качестве встроенных медиа-процессоров для бытовых электронных устройств.

Функции VLIW также были добавлены в конфигурируемые ядра процессора для конструкций система на кристалле (SoC). Например, процессор Tensilica Xtensa LX2 включает технологию под названием Flexible Length Instruction eXtensions (FLIX), которая позволяет выполнять многооперационные инструкции. Компилятор Xtensa C / C ++ может свободно смешивать 32- или 64-битные инструкции FLIX с однооперационными RISC-инструкциями процессора Xtensa, которые имеют ширину 16 или 24 бит. Упаковывая несколько операций в широкое 32- или 64-разрядное командное слово и позволяя этим многооперационным командам смешиваться с более короткими командами RISC, FLIX позволяет разработчикам SoC реализовать преимущества производительности VLIW, устраняя при этом раздувание кода ранние архитектуры VLIW. Infineon Carmel DSP — еще одно ядро ​​процессора VLIW, предназначенное для SoC. В нем используется аналогичный метод улучшения плотности кода, называемый конфигурируемым длинным командным словом (CLIW).

За пределами рынка встроенных процессоров Intel Itanium IA-64 явно параллельное вычисление команд ( EPIC) и Эльбрус 2000 являются единственными примерами широко используемых архитектур ЦП VLIW. Однако архитектуру EPIC иногда отличают от чистой архитектуры VLIW, поскольку EPIC поддерживает полное предсказание команд, вращение файлов регистров и очень длинное командное слово, которое может кодировать непараллельные группы команд. VLIW также получили значительное распространение среди потребителей на рынке графических процессоров (GPU), хотя и Nvidia, и AMD с тех пор перешли на архитектуры RISC, чтобы повысить производительность на других -графические рабочие нагрузки.

ATI Technologies ‘(ATI) и Advanced Micro Devices ‘ (AMD) Микроархитектура TeraScale для графических процессоров (GPU) — это VLIW микроархитектура.

В декабре 2015 года в России произведена первая партия ПК на базе ЦП VLIW Эльбрус-4с.

Обратная совместимость

При использовании кремниевой технологии позволял создавать более широкие реализации (с большим количеством исполнительных модулей), скомпилированные программы для более раннего поколения не могли работать в более широких реализациях, поскольку кодирование двоичных инструкций зависело от количества исполнительных модулей машины.

Transmeta решила эту проблему, включив уровень программного компилятора двоичного кода в двоичный (так называемый преобразование кода ) в свою реализацию Crusoe архитектуры x86. Этот механизм был объявлен для перекомпиляции, оптимизации и преобразования кодов операций x86 во время выполнения во внутренний машинный код ЦП. Таким образом, микросхема Transmeta внутренне является процессором VLIW, эффективно отделенным от набора инструкций x86 CISC , который он выполняет.

Архитектура Intel Itanium (среди прочего) решила проблему обратной совместимости с помощью более общего механизма. Внутри каждой из инструкций с несколькими кодами операции выделяется битовое поле для обозначения зависимости от предыдущей инструкции VLIW в потоке программных инструкций. Эти биты устанавливаются на время компиляции, таким образом освобождая оборудование от вычисления этой информации о зависимостях. Наличие этой информации о зависимости, закодированной в потоке команд, позволяет более широким реализациям выдавать несколько независимых инструкций VLIW параллельно за цикл, в то время как более узкие реализации будут выдавать меньшее количество инструкций VLIW за цикл.

Другим предполагаемым недостатком проектов VLIW является раздувание кода, которое возникает, когда один или несколько исполнительных модулей не имеют полезной работы и, следовательно, должны выполнять No Operation NOP инструкции. Это происходит, когда в коде есть зависимости и конвейеры инструкций должны быть очищены, прежде чем можно будет продолжить последующие операции.

Поскольку количество транзисторов на микросхеме выросло, очевидные недостатки VLIW уменьшились. Популярность архитектур VLIW растет, особенно на рынке встроенных систем, где можно настроить процессор для приложения в системе на кристалле. Встроенные продукты VLIW доступны от нескольких поставщиков, включая FR-V от Fujitsu, BSP15 / 16 от Pixelworks, ST231 от STMicroelectronics, TriMedia от NXP Semiconductors, CEVA-X DSP от CEVA, Jazz DSP от Improv Systems и Silicon Hive. Линия DSP Texas Instruments TMS320 эволюционировала в своем семействе C6xxx, чтобы больше походить на VLIW, в отличие от более раннего семейства C5xxx.

См. Также

• Itanium
• Архитектура Mill
• Явно параллельное вычисление инструкций (EPIC)
• Транспортная триггерная архитектура (TTA)
• Эльбрус (компьютер)
• Movidius (ядро SHAVE)

Ссылки

Внешние ссылки

• Бумага, которая представила VLIW
• Книга по истории Multiflow Computer, новаторская компания VLIW
• ISCA «Best Papers «Ретроспектива на бумаге, которая представила VLIW
• VLIW и встроенную обработку
• FR500 VLIW-архитектура Высокопроизводительный встроенный микропроцессор
• Историческая справка об архитектуре набора команд EPIC
• DIS: архитектура для быстрого выполнения LISP. Аналогичная архитектура VLIW с распараллеливающим компилятором, направленным на LISP.

Архитектура
с командными словами сверхбольшой длины
или со сверхдлинными командами (VLIW, Very
Long Instruction Word) известна с начала 80-х из
ряда университетских проектов, но только
сейчас, с развитием технологии производства
микросхем она нашла свое достойное
воплощение. VLIW — это набор команд,
организованных наподобие горизонтальной
микрокоманды в микропрограммном
устройстве управления.

Идея
VLIW базируется на том, что задача
эффективного планирования параллельного
выполнения нескольких команд возлагается
на «разумный» компилятор. Такой компилятор
вначале исследует исходную программу
с целью обнаружить все команды, которые
могут быть выполнены одновременно,
причем так, чтобы это не приводило к
возникновению конфликтов. В процессе
анализа компилятор может даже частично
имитировать выполнение рассматриваемой
программы. Наследующем этапе компилятор
пытается объединить такие команды в
пакеты, каждый из которых рассматривается
так одна сверхдлинная команда. Объединение
нескольких простых команд в одну
сверхдлинную производится по следующим
правилам:

• количество
  простых команд, объединяемых в одну
  команду сверхбольшой длины, равно числу
  имеющихся в процессоре функциональных
  (исполнительных) блоков (ФБ);

• в
  сверхдлинную команду входят только
  такие простые команды, которые исполняются
  разными ФБ, то есть обеспечивается
  одновременное исполнение всех
  составляющих сверхдлинной команды.

Длина
сверхдлинной команды обычно составляет
от 256 до 1024 бит. Такая метакоманда содержит
несколько полей (по числу образующих
ее простых команд), каждое из которых
описывает операцию для конкретного
функционального блока. Сказанное
иллюстрирует рис, где показан возможный
формат сверхдлинной команды и взаимосвязь
между ее полями и ФБ, реализующими
отдельные операции.

Архитектура
VLIW

Как
видно из рисунка, каждое поле сверхдлинной
команды отображается на свой функциональный
блок, что позволяет получить максимальную
отдачу от аппаратуры блока исполнения
команд.

VLIW-архитектуру
можно рассматривать как статическую
суперскалярную архитектуру. Имеется в
виду, что распараллеливание кода
производится на этапе компиляции, а не
динамически во время исполнения. То,
что в выполняемой сверх-длинной команде
исключена возможность конфликтов,
позволяет предельно упростить аппаратуру
VLIW-процессора и, как следствие, добиться
более высокого быстродействия.

В
качестве простых команд, образующих
сверхдлинную, обычно используются
команды RISC-типа, поэтому архитектуру
VLIW иногда называют nocтRISC-ap-хитектурой.
Максимальное число полей в сверхдлинной
команде равно числу вычислительных
устройств и обычно колеблется в диапазоне
от 3 до 20. Все вычислительные устройства
имеют доступ к данным, хранящимся в
едином многопортовом регистровом файле.
Отсутствие сложных аппаратных механизмов,
характерных для суперскалярных
процессоров (предсказание переходов,
внеочередное исполнение и т. д.), дает
значительный выигрыш в быстродействии
и возможность более эффективно
использовать площадь кристалла.
Подавляющее большинство цифровых
сигнальных процессоров и мультимедийных
процессоров с производительностью
более 1 млрд операций/с базируется на
VLIW-архитектуре. Серьезная проблема VLIW
— усложнение регистрового файла и связей
этого файла с вычислительными устройствами.

Преимущества.
Использование
компилятора позволяет устранить
зависимости между командами до того,
как они будут реально выполняться, в
отличие от суперскалярных процессоров,
где такие зависимости приходится
обнаруживать и устранять «на лету».
Отсутствие зависимостей между командами
в коде, сформированном компилятором,
ведет к упрощению аппаратных средств
процессора и за счет этого к существенному
подъему его быстродействия. Наличие
множества функциональных блоков дает
возможность выполнять несколько команд
параллельно.

Недостатки.
Требуется
новое поколение компиляторов, способных
проанализировать программу, найти в
ней независимые команды, связать такие
команды в строки длиной от 256 до 1024 бит,
обеспечить их параллельное выполнение.
Компилятор должен учитывать конкретные
детали аппаратных средств. При определенных
ситуациях программа оказывается
недостаточно гибкой.

Основные
сферы применения. VLIW-процессоры
пока еще распространены относительно
мало. Основными сферами применения
технологии VLIW-являются цифровые
сигнальные процессоры и вычислительные
системы, ориентированные на архитектуру
IA-64. Наиболее известной была VLIW-система
фирмы Multiflow Computer, Inc. (Уже не существующей.)
В России VLIW-концепция была реализована
в суперкомпьютере Эльбрус 3-1 и получила
дальнейшее развитие в его последователе
— Эльбрус-2000 (Е2к). К VLIW можно причислить
семейство сигнальных процессоров
TMS320C6x фирмы Texas Instruments. С 1986 года ведутся
исследования VLIW-архитектуры в IBM. В
начале 2000 года фирма Transmeta заявила
процессор Crusoe, представляющий собой
программно-аппаратный комплекс. В нем
команды микропроцессоров серии х86
транслируются в слова VLIW длиной 64 или
128 бит. Оттранслированные команды
хранятся в кэш-памяти, а трансляция при
многократном их использовании производится
только один раз. Ядро процессора исполняет
элементы кода в строгой последовательности.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #