• Home
  • /
  • RISC-V
  • /
  • 2. Зачем разрабатывать новый набор команд? (RISC-V)

2. Зачем разрабатывать новый набор команд? (RISC-V)

 

Возможно, наиболее распространённый вопрос во время разработки RISC-V состоял в том, почему существует какая-либо необходимость в новой архитектуре системы команд. В конечном счёте, в широком применении существует некоторое количество коммерческих АСК, а повторное использование одного из них позволит избежать значительных трудозатрат и расходов на перенос программного обеспечения на новую платформу. В нашем сознании, два главных недостатка перевешивают данное соображение.

Первое, все популярные коммерческие АСК являются проприетарными. Продавая реализации своей АСК в виде IP-ядер или готовой микросхемы, поставщики АСК имеют довольно прибыльный бизнес. Таким образом, они не приветствуют размещение своих разработок в свободном доступе, что могло бы уменьшить их доходы. С учетом данного соображения, все представленные в работе проприетарные АСК исключают возможность создания и выкладывания полноценной их RTL-реализации, однако не запрещают проводить любые формы академического исследования архитектуры вычислительный системы на их примере. Это также создаёт барьер для коммерциализации успешных исследовательских идей.

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

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

 2.1 MIPS

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

В своём первоначальном воплощении, система команд MIPS пользовательского уровня  включала всего 58 машинных команд и была проста для реализации в виде конвейера с последовательным выполнением команд. Понадобилось более 30 лет для того, чтобы изначальная реализация системы команд MIPS эволюционировала в намного большую архитектуру, в данный момент включающую в себя около 400 машинных команд. В то время как микроархитектурная реализация ядра MIPS-I является хорошим примером в рамках понимания академического проектирования архитектуры компьютерных систем, его АСК имеет ряд технических недостатков, делающих его менее привлекательным для высокопроизводительных реализаций:

  • АСК слишком сильно оптимизирована для конкретных микроархитектурных моделей, для пятиступенчатого конвейера с последовательным выполнением команд. Ветвления и операции перехода задерживаются одной машинной командой, усложняя суперскалярные и суперконвейерные реализации. Задержанные условные переходы (delayed branches) увеличивают размер кода и растрачивают полосу пропускания выдачи команд, когда слот задержанного выполнения (delay slot) не может быть выставлен соответствующим образом. Даже для классического пятиступенчатого конвейера, исключение слота задержанного выполнения и добавление буфера целевых адресов ветвлений (branch target buffer) обычно приводит к лучшей абсолютной производительности и производительности на единицу площади.
  • Архитектура MIPS-I включала в себя и другие конфликты конвейера: в операциях загрузки данных, операциях умножения и деления. Однако более поздние версии АСК устранили данные недостатки и могут предложить более высокую производительность, отражая тот факт, что блокирующие действия по указанным конфликтам конвейера одновременно более просты для программного обеспечения. С другой стороны, слот задержанного выполнения не может быть устранён при сохранении совместимости с предыдущими версиями.
  • АСК предоставляет плохую поддержку для позиционно-независимого (position-independent) кода, и, следовательно, динамическую компоновку. Прямой переход машинных команд является псевдо-безусловным (pseudo-absolute) вместо того, чтобы быть относительным по отношению к программному счетчику. Таким образом, прямой переход делает его бесполезным для позиционно-независимого кода, вместо этого, MIPS использует исключительно косвенный переход, значительного увеличивающий размер кода и стоимость выполнения операций. (В версии MIPS 2014 года была улучшена адресация относительного счётчика команд, но вызовы функции адресации в целом по-прежнему выполняют более чем одну машинную команду).
  • 16-ти разрядная ширина непосредственной адресации занимает значительное пространство кодирования , оставляя лишь небольшую долю для пространства операционного кода.  В версии 2014 года для расширений АСК доступно 1/64 часть от общего пространства кодирования. Когда разработчики MIPS стремились сократить размер кода с помощью сжатого кодирования команд, у них не было выбора кроме того, как создать дополнительное кодирование команд, задействованное с помощью переключателя режима. Это произошло из-за того, что разработчики не смогли поместить новые машинные команды в изначальное пространство кодирования.
  • Умножение и деление использует специальные архитектурные регистры, увеличивающие размер рабочего окружения, количество машинных команд, размер кода и микроархитектурную сложность.
  • АСК предполагает, что блок операций с плавающей точкой является отдельным сопроцессором и не оптимален для однокристальной реализации. Например, преобразования с плавающей запятой в целое записывают свой результат в набор регистров с плавающей запятой, и, как правило, это вызывает необходимость в дополнительной команде перемещения при использовании полученного результата преобразования. Усугубляет данную проблему еще и тот факт, что перемещения между наборами регистров целочисленного типа и с плавающей запятой имеют программно-незащищённый слот задержанного выполнения.
  • В стандарте ABI, зарезервировано два целочисленных регистра для ядра программного обеспечения. Данные регистры уменьшают количество доступных регистров для пользовательских программ. Но даже несмотря на это, регистры имеют ограничения в использовании ядра, так как они не защищены от пользовательского доступа.
  • Обработка особых ситуаций невыровненных загрузок и сохранения специальных машинных команд потребляет значительное пространство операционного кода и усложняет всю архитектуру кроме ее самых простых реализаций.
  • Разработчики пренебрегли целочисленными величинами в машинных командах сравнения и разветвления, а также соотношением тактовая частота/число тактов за команду (Cycle Per Instruction). Правда на сегодняшний день с появлением предсказателя условных переходов (branch prediction) и переходом на статическую КМОП логику данное соотношение все менее актуально.

Отложим технические вопросы в сторону, MIPS является неподходящей архитектурой для многих применений, поскольку она является проприетарной системой команд. Исторически, патенты MIPSTechnology на невыровненную загрузку и хранение машинных команд мешали другим компаниям в полной реализации данной АСК. В одном из случаев,  иски адресовывались той компании, чья MIPS реализация полностью исключала сами команды, но имела их эмуляцию в ядре программного обеспечения, и это все равно считалось нарушением патента MIPS.  Несмотря на то, что с тех пор срок действия патентов уже истёк, MIPS остаётся торговой маркой Imagination Technologies, и нельзя заявлять о совместимости с архитектурой MIPS без их разрешения.

2.2 SPARC

Архитектура Oracle’s SPARC, изначально разработанная Sun Microsystems, ведёт своё происхождение к проектам Беркли  RISC-I и RISC-II. Самая популярная 32-битная версия АСК ,SPARCV8 не является чрезмерно сложной: целочисленные АСК пользовательского уровня имеют простое, нормальное кодирование и включают в себя всего лишь 90 машинных команд. Аппаратная поддержка для стандарта IEEE 754-1985 с плавающей запятой добавила 50 новых машинных команд, а супервизорный режим еще 20. Несмотря на это, несколько проектных решений данной архитектуры делают ее чуть менее привлекательной для реализации чем MIPS-I:

  • Для ускорения вызова функций, SPARC использует большой набор регистровых окон. В границе вызова процедур, регистровое окно сдвигается, предоставляя вызываемой программе внешнее представление из нового набора регистров. Такая конструкция исключает необходимость сохранять и восстанавливать код для calle-saved регистра. Данный подход позволяет уменьшить размер кода и, как правило, улучшает производительность. Если же рабочий набор процедуры стека вызовов превышает количество регистровых окон, то это будет вести к значительному снижению производительности: операционная система должна регулярно ссылаться на указатель окна переполнения сверху и снизу. Значительно расширенное архитектурное состояние увеличивает стоимость рабочего цикла в переключениях контекста (context switching) программы, а необходимость запуска операционной системы для очистки регистровых окон в общей сложности не позволяет реализовать чистую многопоточность на пользовательском уровне.
  • Регистровые окна приводят к значительному увеличению площади и энергопотреблению практически во всех реализациях архитектуры. Методы, направленные на снижение указанных недостатков, будут усложнять в частности суперскалярную реализацию. Например для того, чтобы избежать инициализации большого количества портов через архитектурный набор регистров, UltraSPARC-III предоставляет теневую копию (shadow copy) активного регистрового окна. Тененвая копия должна быть обновлена в сдвигах регистровых окон, вызывая тем самым разрыв конвейера на большинстве вызовов и возвратов функции. Реализации данной АСК от компании Fujitsu с внеочередным исполнением команд (out-of-order execution) имело аналогичные методы, свертывая регистровые окна и адресуя логику в схему переименовывания регистров.
  • Ветвления используют коды условий, которые добавляют архитектурные состояния и усложнённые реализации при помощи создания дополнительных зависимостей между некоторыми машинными командами. Микроархитектуры с внеочередным выполнением команд требуют отдельного переименования кодов условий для устранения узкого места в виде частого индексирования. Отсутствие объединенной команды сравнения-разветвления (compare-and-branch) также увеличивают статический и динамический счётчик команд для последовательности общего кода.
  • Машинные команды, которые хранят и загружают смежные пары набора регистров, являются привлекательными для простых микроархитектур, поскольку они повышают пропускную способность архитектуры при небольшой аппаратной сложности. К сожалению, данные команды усложняют реализации с переименованием регистров, так как данные в регистровом файле больше не располагаются рядом.
  • Перемещения между целочисленным набором регистров и с плавающей точкой должны использовать систему памяти как промежуточное устройство, ограничивая тем самым производительность для кода смешанного формата.
  • АСК демонстрирует неопределённые исключения с плавающей запятой через архитектурно незащищенную deferred-trap очередь, которая обеспечивает супервизорному ПО необходимую информацию для восстановления состояния процессора на подобном исключении.
  • Единственная атомарная операция обращения к памяти процессора является выборка и хранение (fetch-and-store), чего недостаточно для реализаций многих свободных от ожидания (waitfree) структур данных.

SPARC разделяет многочисленные недальновидные свойства архитектур, основанных на других RISC архитектурах 1980-х годов. SPARC был разработан для осуществления пятиступенчатого конвейера с последовательным выполнением команд, и ее АСК отражает данное предположение. SPARC имеет слоты задержанного выполнения, множество уязвимостей данных и конфликтов по управлению, которые усложняют генерацию машинной программы и не способствуют более агрессивным реализациям данной АСК. Кроме того, отсутствует поддержка адресации позиционно-независимых данных. Наконец, SPARC невозможно быстро модернизировать для поддержки расширений сжатой АСК, поскольку она не располагает достаточным количеством свободного пространства кодирования.

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

2.3 Alpha

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

  • В дополнение к этому, DEC чрезмерно оптимизировала Alpha для микроархитектур с последовательным выполнением команд и добавила несколько функций, которые являются менее желательными для современных реализаций:
  • В погоне за высокой тактовой частотой, оригинальная версия АСК отказалась от 8-ми и 16-ти разрядных загрузок и сохранений, эффективно создавая систему памяти с пословной адресацией. Для того, чтобы компенсировать производительность в приложениях, активно использующих данные операции, они добавили специальные машинные команды невыровненной загрузки и хранения, а также несколько целочисленных машинных команд для реорганизации скорости работы. Тем не менее производительность в приложениях по- прежнему оставляла желать лучшего, а реализовывать некоторые драйвера устройств с данной АСК вообще не представлялось возможным. В конечном итоге разработчики поняли ошибку выбранного пути и добавили к АСК полусловную загрузку и хранение. Но она по-прежнему была обременена ранее используемыми машинными командами, требующими выравнивания-обработки (alignment-handling).
  • Для того, чтобы облегчить внеочередное выполнение высоколатентных команд с плавающей запятой, Alpha имеет неопределённую модель внутренних прерываний для операций с плавающей запятой (foating-point trap model). Данное решение могло бы быть приемлемым в отдельном случае, однако АСК при этом определяет, что флаги исключения и исходные значения, если они заданы, должны быть установлены при помощи программных процедур. Данное сочетание имеет катастрофические последствия для IEEE-754-совместимых программ: команды, препятствующие исключению, должны быть вставлены после большинства арифметических команд в операциях с плавающей запятой.
  • Alpha испытывает недостаток в машинных командах целочисленного деления, предложив вместо использования программного алгоритма Ньютона-Рафсона итерационную схему. Данный подход значительно увеличивает количество машинных команд для некоторых программ и оставляет доступным только небольшое количество аппаратных ресурсов. Удивительным следствием является то, что операция деления с плавающей запятой значительно быстрее целочисленного на большинстве реализаций.
  • Как и в случае с его RISC предшественником, архитектура не дает возможности к расширению при помощи сжатой системой команд, и поэтому, для модернизации АСК оставлено недостаточное пространство операционного кода.
  • АСК содержит условные перемещения, которые усложняют микроархитектуру с переименованием регистров: если условие перемещения не соблюдается, машинные команды должны копировать старое значение в новый физический целевой регистр. Это фактически делает условные перемещения единственной машинной командой в АСК, считывающей три исходных операнда.

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

Alpha также заостряет внимание на существенном риске в использовании коммерческих АСК: они попросту могут прекратить свое существование. Незадолго после того, как Compaq приобрела то, что осталось от ослабшей DEC в конце 1990-х годов, она приняла решение постепенно сократить Alpha в пользу архитектуры Intel Itanium. Compaq продала Intelу интеллектуальную собственность Alpha, и скоро после этого, компания HP, купившая Compaq, выпустила заключительную реализации Alpha в 2004 году.

2.4 ARMv7

ARMv7 — это популярная 32-битная АСК схожая с RISC-архитектурами, до сегодняшнего дня она является наиболее широко реализованной архитектурой в мире. Когда мы обдумывали, разрабатывать ли нам наш собственный набор команд или использовать существующие, ARMv7 являлся настоящей альтернативой в нашем выборе в связи с большим количеством портированного ПО, и, из-за его повсеместного использования во встраиваемых системах и мобильных устройствах. В конечном счёте мы не смогли освоить ARMv7, т.к. это закрытый стандарт. Строго запрещается создавать собственные подмножества данной АСК или расширять его новыми машинными командами. Даже если бы разработчики имели какие-либо новые наработки для самой микроархитектуры, то их невозможно было бы внедрить в АСК без специальной архитектурной лицензии от компании ARM.

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

  • В то время не было поддержки 64-битной адресации, и АСК не хватило аппаратных ресурсов для поддержки стандарта IEEE 754-2008. (как будет описано в следующем разделе,  ARMv8 лишена данных недостатков).
  • Подробные детали привилегированной архитектуры проникают на определение архитектуры пользовательского уровня. ARMv7 не является классически виртуализируемой (classically virtualizable) архитектурой, в частности из-за того, что машинная команды возврата из исключения (RFE) не определена для программного исключения (trap), исполняемого в пользовательском режиме. ARM добавила гипервизорный привилегированный режим в недавних ревизиях архитектуры, но на момент написания данной статьи, в ARMv7 невозможно реализовать классическую виртуализацию без динамического двоичного перевода (binary translation или software virtualization).
  • ARMv7 размещена вместе с сокращённой АСК, которая имеет 16-разрядные машинные команды фиксированной длины, называемые Thumb (Бегунок). Thumb предлагает конкурентоспособный размер кода, однако имеет низкую производительность, особенно в операциях с плавающей запятой в ресурсоёмком коде. Машинные команды переменной длины, называемые Thumb-2, последовали позже и обеспечили гораздо большую производительность. К сожалению, с тех пор, как была создана Thumb-2  после определения основной АСК ARMv7, 32-битные машинные команды Thumb-2 кодировались иначе чем 32-битные машинные команды основной АСК. (16-ти разрядные машинные команды в Thumb-2 также кодируются иначе, чем 16-ти разрядные команды в исходной АСК Thumb). Действительно, дешифраторы машинных команд требуют понимания трёх АСК, увеличивая тем самым энергопотребление, латентность архитектуры и стоимость разработки.
  • АСК имеет множество особенностей, которые усложняют практические реализации. ARMv7 не является в сущности архитектурой с регистрами общего назначения: программный счётчик является одним из адресуемых регистров, тем самым подразумевая, что непосредственно любая машинная команда может изменить поток команд управления. Что еще хуже, наименее значащий бит (least-significant bit) программного счётчика показывает, какая система команд в данный момент является исполняемой (ARM или Thumb) – всего лишь простая команда ADD может изменить исполняемую систему команд на процессоре в текущий момент времени! Использование кодов условия для команд условного перехода и предсказания в дальнейшем усложняет высокопроизводительные реализации.

ARMv7 является огромной и сложной АСК. Среди ARM и Thumb, есть более 600 машинных команд, определенных только лишь в одной целочисленной АСК. NEON, имеющий целочисленную архитектуру SIMD,  (один поток команд — много потоков данных, Single InstructionMultiple Data stream processing) и расширение с плавающей запятой добавляет еще более сотни машинных команд. Даже, если практическая реализация ARMv7 являлась для нас юридически достижимой задачей, то она была бы крайне сложной с технической точки зрения.

2.5 ARMv8

В 2011 году, год спустя после начала работы с проектом RISC-V , ARM анонсировала полностью переработанную АСК, ARMv8 с 64-битной адресацией и расширенным целочисленным набором регистров. Новая архитектура убрала несколько функций ARMv7 которые были сложны в реализации: например, счетчик программы больше не является частью целочисленного набора регистров; команды больше не являются предикатными; удалены команды блочной передачи (load-multiple и store-multiple); дешифрация команд была упорядочена. Однако многие проблемы остались, включая использование флагов состояния (коды условий) и “не совсем регистров общего назначения”. (регистр связи определен неявно, в зависимости от контекста, x31 в равной степени является либо указателем стека, либо жестко привязан к нулю). И вдобавок были добавлены следующие недостатки: фактически обязательное использование массивных подслов SIMD-архитектуры.  В итоге, АСК ARMv8 очень сложна и громоздка: в ней присутствует порядка 1070 команд, включающих 53 формата данных и восемь режимов адресации, все это требует 5778 страниц  документации. Возможно будет неожиданностью, что важные особенности данной АСК были оставлены совсем без внимания: к примеру АСК испытывает недостаток в командах сравнения и ветвления.

Как и большинство рассматриваемых нами АСК, ARMv8 тесно переплетает пользовательскую и привилегированную архитектуры, часто теми способами, которые раскрывают базовую реализацию. В одном лице приведем необъяснимый пример – который комбинирует сложную семантику, неопределенное поведение, регистровую зависимость свойств предположительно регистров общего назначения – команды (load-pair) могут подвергнуть пользовательское пространство неточным исключением:

“Если кодировка команд указывает на предварительную индексную адресацию или пост-индексную адресацию, и (t == n || t2 == n) && n != 31, то затем может произойти одно из следующих событий:

  • Команда не определена (UNDEFINED)
  • Команда выполняется как NOP (нет операций)
  • Команда выполняет загрузку, используя указанный режим адресации, и базовый регистр устанавливается в неизвестное значение (UNKNOWN value). Кроме того, если во время такой команды возникает исключение, то базовый регистр может быть испорчен таким образом, что данную команду невозможно будет повторить”.

Кроме того, с введением ARMv8, ARM отказалась от поддержки сжатой кодировки команд, а плотный набор команд Thumb не захватил с собой 64-битного адресного пространства. Правдой и является то, что ARMv8 крайне компактен для АСК фиксированной ширины, однако, как мы покажем в главе 5, она не может конкурировать в объеме программного кода с АСК переменной ширины. Безусловно, тот факт, что первые 64-битные реализации АСК имели на 50% больше кэша команд, чем его 32-разрядные аналоги не является случайностью.

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

2.6 OpenRISC

Проект OpenRISC представляет собой проект разработки процессора с открытым исходным кодом, который появился из образовательной DLX–архитектуры Хенеси и Патерсона (Hennessy and Patterson’s), описанной в авторитетном учебнике про архитектуры вычислительных систем (Computer Architecture: A Quantitative Approach. 3rd ed. San Francisco). Как свободная и открытая АСК, OpenRISC юридически подходит для использования в академических, исследовательских и промышленных реализаций. Как и архитектура DLX , он имеет несколько технических недостатков, которые ограничивают его применимость:

  • Проект OpenRISC главным образом является открытой разработкой процессора, а не открытой спецификацией АСК. АСК и ее реализация тесно связаны друг с другом.
  • Фиксированная 32-разрядная кодировка с 16-разрядной непосредственной адресацией делает невозможным сжатые расширения АСК
  • Ревизия 2008 стандарта IEEE754 не поддерживается аппаратно
  • Коды условий, используемые в ветвлении и в условных переходах, усложняют высокопроизводительную реализацию
  • АСК обеспечивает плохую поддержку для позиционно-независимой адресации данных
  • OpenRISC не является виртуализируемой в классическом понимании, т.к. для нормального функционирования возвращение исключения L.RFE определено в пользовательском режиме.

Когда в 2010 году мы впервые исследовали OpenRISC , его АСК имела два дополнительных недостатка: обязательное отложенное ветвление, и отсутствие 64-битного адресного пространства. К чести разработчиков, оба данных недостатка были исправлены: отложенное ветвление стало опциональным, разработана 64-разрядная версия (но насколько нам известно, никогда не реализовывалась). В конечном счете, мы предположили, что для наших целей, лучше всего было бы начать все с чистого листа, а не модифицировать OpenRISC.


Автор: Andrew Shell Waterman

Источник: https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf


Оглавление