Основы AS/400
Шрифт:
Давайте разберемся, почему VLIW-технология вызывает столь большой интерес. Дело в том, что ее применение может изменить генеральное направление развития современной информатики: от суперскалярных RISC-процессоров — вспять, к повышению сложности схем на кристалле. Ранее, такие процессоры с повышенной сложностью мы назвали Brainiac. Более простые архитектуры, такие как Speed Demons, могут «крутиться» быстрее и достигать больших тактовых частот. VLIW переносит сложность на компиляторы, позволяя создавать более быстрые процессоры.
Главный недостаток RISC-процессоров и причина сложности аппаратуры — трудности в поддержании
Почему же суперскалярный RISC-процессор не может диспетчировать 8-16 команд за цикл? Во-первых, мешает ограничение аппаратной технологии: у обычного RISC-процессора для этого просто мало независимых функциональных узлов. Другая причина в том, что в цикле недостаточно времени, чтобы проанализировать 8-16 команд, определить, какие функциональные устройства не заняты, и отправить каждую команду на соответствующий узел; увеличение же времени цикла сократит производительность процессора. Третье ограничение — генерировать для каждого цикла по 8-16 независимых команд не способен компилятор.
Развитие аппаратных технологий позволяет создать однокристальный процессор с 8, 16 и даже большим числом функциональных узлов. Технология компиляторов также развилась достаточно, чтобы распознать многократный параллелизм команд и обеспечить работой больше функциональных узлов.
Но возможность выбирать на выполнение большее число команд бесполезна, если аппаратура суперскалярного RISC-процессора может выполнять одновременно лишь малое их число. VLIW-технология решает эту проблему, снимая с аппаратуры процессора задачу распределения команд. Вместо того чтобы, как в RISC-процессоре, анализировать каждую инструкцию в потоке команд и затем распределять их по одной в функциональные узлы, компилятор VLIW генерирует отдельную команду для каждого функционального узла на каждом цикле. Например, если функциональных узлов 16, то компилятор генерирует для каждого процессорного цикла 16 команд; но в отличие от RISC-процессора, который анализирует, в какой функциональный узел направлять каждую команду, VLIW-процессор просто посылает первую команду в первый узел, вторую — во второй и т. д. Конечно, если на каком-то цикле у компилятора не оказывается команды для некоторого узла, он по-прежнему должен сгенерировать код «нет операции». Так как VLIW-процессор ни о чем не «размышляет», то его время цикла меньше, чем время цикла суперскалярного RISC-процессора. Меньшее время цикла и увеличенная степень параллелизма исполнения команд, достигаемая посредством загрузки большего числа функциональных узлов, дает VLIW преимущества перед RISC.
Вы можете спросить, откуда взялось название «VLIW»2. Компилятор упаковывает независимые команды для каждого цикла в одно очень длинное слово — отсюда и название. На каждом цикле процессор выбирает по одному такому очень длинному слову из своего кэша команд. Таким образом, если каждая из 16 команд занимает 4 байта, то в результате получается 64-байтовое (512-битное)
Генератор кода компилятора (аналог транслятора AS/400) для VLIW-процессора находит процессору достаточно работы на каждом цикле и генерирует соответствующие команды:. Если на каждом цикле исполняется от 4 до 20 полезных команд, то на одном процессоре можно добиться производительности на уровне миллиарда команд в секунду.
Самая большая проблема VLIW в том, что генератор кода компилятора должен быть тесно связан с аппаратурой. Чтобы генерировать команды для каждого функционального узла процессора, компилятор должен иметь точную информацию, сколько узлов на микросхеме, какие они и как связаны друг с другом. В результате, практически невозможно использовать код, сгенерированный таким компилятором на любом модифицированном процессоре, так как у них отсутствует двоичная совместимость (или они имеют разное число функциональных узлов).
Ранее предполагалось, что Intel использует в микросхеме Merced трансляцию команд х86 и IA-64 в команды VLIW «на лету», аналогично Pentium II и Pentium Pro, где команды х86 и IA-64 «на лету» транслируются в последовательность RISC-подобных команд непосредственно микросхемой. Intel называет эти RISC-подобные команды микрооперациями и описывает данный прием как динамическое исполнение. Затем ядро процессора исполняет эти микрооперации конвейерным устройством, которое выглядит точно так же, как и любой RISC-процессор.
Intel не первая применила такой механизм. Точно так же работал процессор Nx586 другого производителя микросхем х86 — NexGen, теперь приобретенной AMD (Advanced Micro Devices). NexGen называла этот подход внутренними командами RISC86. Теперь он использован в другой совместимой с х86 микросхеме AMD — К6. Все эти продукты продемонстрировали, что динамическое исполнение удачно для RISC-процессора. В то же время оно может не очень хорошо сказываться на объеме параллелизма в потоке команд VLIW-процессора.
Далее RISC-процессор анализирует следующие 3 — 6 команд и направляет их в максимально возможное в данный момент количество узлов процессора. RISC-компиляторы отвечают за помещение в поток команд независимых друг от друга инструкций, чтобы за один цикл можно было отправить на выполнение их максимальное количество. Генератор кода компилятора обрабатывает промежуточное представление и генерирует двоичные машинные команды. Обычно для предоставления процессору достаточного числа независимых команд требуется анализ команд некоторого участка промежуточного представления.
В VLIW-машине число функциональных устройств сильно возрастает, что нужно для достижения большего параллелизма. В ближайшее время можно вполне ожидать появления процессоров, имеющих от 16 до 32 (а в будущем и более) функциональных узлов. Для обеспечения загрузки командами компьютеров такого типа генератору кода компилятора потребуется проанализировать гораздо больший диапазон промежуточного представления. Для генерации команд каждого цикла компилятору придется просмотреть, возможно, сотни и даже тысячи промежуточных команд. При использовании динамического подхода «на лету», для генерации команды VLIW просматривается лишь несколько команд. Способность эффективной загрузки большого числа функциональных узлов в этом случае остается под большим вопросом.