Современные RISC-архитектуры

Немного критики RISC архитектур от создателей RISC-V

MIPS

Архитектура набора команд MIPS является одной из самых элегантных RISC ISA. Первоначально разработанная в Стэнфорде в начале 1980-х годов, на ее дизайн большое влияние оказал мини-компьютер IBM 801. Обе архитектуры представляют собой архитектуры типа load/store с регистрами общего назначения, в которых доступ к памяти осуществляется только с помощью инструкций, которые копируют данные в регистры и из них, а арифметика работает только с регистрами. Такая конструкция снижает сложность как набора команд, так и аппаратного обеспечения, облегчая недорогую конвейерную реализацию, полагаясь при этом на улучшенные технология компилятора. MIPS был впервые коммерчески реализован в процессоре R2000 в 1986 году.

В своем первоначальном воплощении набор целочисленных команд пользовательского уровня MIPS состоял всего из 58 инструкций и был прост в реализации в виде конвейера с одним выпуском по порядку. Постепенно набор команд превратился в гораздо более крупный ISA, который теперь содержит около 400 инструкций.

В то время как простые микроархитектурные реализации MIPS-I вполне доступны академическим компьютерным архитекторам, ISA имеет ряд технических недостатков, которые делают его менее привлекательным для высокопроизводительных реализаций:

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

Другие риски конвейера, включая риски данных при загрузке, умножении и делении, были обнаружены в MIPS-I, но более поздние версии ISA удалили эти бородавки, отражая тот факт, что блокировка этих опасностей одновременно проще для программного обеспечения и может обеспечить более высокую производительность. Слот задержки перехода, с другой стороны, не может быть удален при сохранении обратной совместимости.

ISA обеспечивает слабую поддержку позиционно-независимого кода (positional independent code - PIC) и, следовательно, динамической компоновки. Инструкции прямого перехода являются псевдоабсолютными, а не относительными к программному счетчику, что делает их бесполезными в PIC; вместо этого MIPS использует исключительно косвенные переходы, при значительном размере кода и снижении производительности. (В версии MIPS 2014 улучшена адресация относительно ПК, но вызовы функций относительно ПК по-прежнему обычно требуют более одной инструкции.)

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

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

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

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

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

Архитекторы опустили инструкции сравнения целочисленных величин и ветвления - соотношение тактовой частоты и CPI, которое сегодня менее уместно с появлением предсказания ветвления и переходом к статической логике CMOS.

Помимо технических проблем, MIPS непригоден для многих целей, поскольку является проприетарным набором команд. Исторически сложилось так, что патент MIPS Technologies на несогласованные инструкции загрузки и сохранения помешал другим полностью внедрить ISA. В одном случае судебный процесс был направлен против компании, чьи реализации MIPS исключали инструкции, утверждая , что эмуляция инструкций в программном обеспечении ядра по-прежнему нарушает патент. Хотя срок действия патента с тех пор истек, MIPS остается торговой маркой Imagination Technologies; MIPS совместимость не может быть заявлена без их разрешения.

И да - перевод архитектуры MIPS в открытую ее не спас - лавинообразное повальное увлечение и переход на RISC-V вынудил прекратить поддержку архитектуры даже Imagination Technologies.

SPARC

Архитектура Oracle SPARC, первоначально разработанная Sun Microsystems, ведет свое происхождение от проектов Berkeley RISC-I и RISC-II. Самая последняя 32-разрядная версия ISA, SPARC V8, не является чрезмерно сложным: целочисленный ISA пользовательского уровня имеет простую, обычную кодировку и содержит всего 90 инструкций. Аппаратная поддержка IEEE 754-1985 floating point добавляет еще 50 инструкций, а режим супервизора - еще 20. Тем не менее, несколько дизайнерских решений ISA делают его несколько менее привлекательным для реализации, чем MIPS.

Для ускорения вызовов функций SPARC использует большой оконный файл регистров. На границах вызова процедуры окно сдвигается, создавая у вызываемого объекта видимость нового набора регистров. Такая конструкция устраняет необходимость в коде сохранения и восстановления регистра, сохраняемом вызываемым пользователем, что уменьшает размер кода и, как правило, повышает производительность. Однако, если рабочий набор стека вызовов процедур превышает количество окон регистрации, производительность резко снижается: операционная система должна регулярно вызываться для обработки окна поверх потоков и под потоками.

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

Аппаратно регистровые окна занимают значительную площадь и потребляют много энергии для всех реализаций. Методы снижения их стоимости, в частности, усложняют суперскалярные реализации . Например, чтобы избежать выделения большого количества портов во всем наборе архитектурных регистров, UltraSPARC-III предоставляет теневую копию активного регистрового окна. Теневая копия должна обновляться при смене регистрового окна, что приводит к разрыву конвейера при большинстве вызовов и возвращений функций. Реализации неупорядоченного выполнения Fujitsu пошли на столь же героический шаг, объединив логику адресации окна регистра в схему переименования регистров.

В ветвях используются коды условий, которые дополняют архитектурное состояние и усложняют реализации, создавая дополнительные зависимости между некоторыми инструкциями. Вышедшие из строя микроархитектуры с переименованием регистров нуждаются в отдельном переименовании условия коды для устранения частых проблем с сериализацией. Отсутствие объединенной инструкции compareand-branch также увеличивает количество статических и динамических команд для общих кодовых последовательностей.

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

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

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

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

SPARC разделяет многие близкие черты ISA других RISC-архитектур 1980-х годов.

Он был разработан для реализации в виде одноступенчатого, последовательного, пятиступенчатого конвейера, и вся ISA это подтверждает. В SPARC есть интервалы задержки ветвления и множество уязвимостей для данных и управления, которые усложняют генерацию кода. Кроме того, отсутствует поддержка позиционно-независимой адресации данных (ну так ли это это необходимо - вопрос на самом деле).

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

В отличие от других коммерческих RISC архитектур, SPARC V8 является открытым стандартом, к чести Sun. SPARC International продолжает предоставлять разрешительные лицензии на V8 и V9, 64-разрядную версию ISA, за административный сбор в размере 99 долларов. Открытый ISA привел к появлению свободно доступных реализаций, две из которых являются производными от собственной микроархитектуры Sun Niagara. Увы, продолжающаяся разработка архитектуры Oracle SPARC [74] является проприетарной, и высокопроизводительное программное обеспечение, скорее всего, последует их примеру, оставив позади реализации более старого открытого набора команд.

Alpha

Архитекторы Digital Equipment Corporation воспользовались несколькими годами ретроспективного анализа, когда в начале 1990-х годов они разработали свой RISC ISA, Alpha. Они опустили многие из наименее привлекательных функций первых коммерческих RISC ISA, включая интервалы задержки перехода, коды условий и окна регистрации, и создали 64-разрядный ISA с адресным пространством, который был четко спроектирован, прост в реализации и обладал высокой производительностью. Кроме того, архитекторы Alpha тщательно выделили большинство деталей привилегированной архитектуры и аппаратная платформа, стоящая за абстрактным интерфейсом, библиотека привилегированной архитектуры (PALcode).

Тем не менее, DEC чрезмерно оптимизировала альфа-версию для микроархитектур in-order и добавила несколько функций, которые менее чем желательны для современных реализаций:

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

Чтобы облегчить выполнение инструкций с плавающей точкой с длительной задержкой выполнения, Alpha имеет неточную модель ловушки-исключения с плавающей точкой. Это решение могло бы быть приемлемым по отдельности, но ISA также определяет, что флаги исключений и значения по умолчанию, при желании, должны предоставляться программными процедурами. Такое сочетание губительно для программ, совместимых с IEEE-754: инструкции с барьером ловушки должны вставляться после большинства арифметических инструкций с плавающей запятой (или, если соблюдается список ограничений на генерацию кода в стиле барокко, один раз на базовый блок).

В Alpha отсутствует инструкция по целочисленному делению, вместо этого предлагается использовать программное обеспечение.

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

Как и в случае с его предшественниками RISC, не было продумано возможное расширение сжатого набора команд, и поэтому для его обновления остается недостаточно места для кода операции.

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

Действительно, первая реализация DEC с выполнением не по порядку использовала некоторые ухищрения , чтобы избежать дополнительного пути к данным для этой инструкции. Выполненный Alpha 21264 команда условного перемещения путем разделения ее на две микрооперации, первая из которых оценивала условие перемещения, а вторая выполняла перемещение.

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

Вскоре после того, как Compaq приобрела то, что осталось от слабеющего DEC в конце 1990-х, они решили отказаться от Alpha в пользу архитектуры Intel Itanium. Compaq продала Интеллектуальная собственность Alpha перешла к Intel [80], и вскоре после этого HP, которая с тех пор приобрела Compaq, выпустила окончательную реализацию Alpha в 2004 году.