Хабрахабр

[Перевод] Недостатки RISC-V

Изначально я написала этот документ несколько лет назад, будучи инженером по проверке ядра исполнения команд (execution core verification engineer) в ARM. Конечно, на моё мнение повлияла углублённая работа с исполнительными ядрами разных процессоров. Так что делайте на это скидку, пожалуйста: может, я слишком категорична.

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

0. Статья изначально описывала набор команд RISC-V 2. 2 в ней сделаны некоторые обновления.
Для версии 2.

Набор команд RISC-V доведён до абсолютного минимума. Большое внимание уделяется минимизации числа инструкций, нормализации кодирования и т. д. Это стремление к минимализму привело к ложным ортогональностям (таким как повторное использование одной и той же инструкции для переходов, вызовов и возвратов) и обязательной многословности, что раздувает и размер, и количество инструкций.

Например, вот код C:

int readidx(int *p, size_t idx)

Это простой случай индексирования массива, очень распространённая операция. Так выглядит компиляция для x86_64:

mov eax, [rdi+rsi*4]
ret

или ARM:

ldr r0, [r0, r1, lsl #2]
bx lr // return

Однако для RISC-V необходим такой код:

slli a1, a1, 2
add a0, a1, a1
lw a0, a0, 0
jalr r0, r1, 0 // return

Симплификация RISC-V упрощает декодер (т. е. фронтенд CPU) за счёт выполнения большего количества инструкций. Но масштабирование ширины конвейера — сложная проблема, в то время как декодирование слегка (или сильно) нерегулярных инструкций хорошо реализуется (основная трудность возникает, когда трудно определить длину инструкции: это особенно проявляется в наборе команд x86 с многочисленными префиксами).

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

Последние используются часто и с высокой производительностью. Мы должны отличать «сложные» специфические инструкции CISC-процессоров — усложнённые, редко используемые и малооэффективные инструкции — от «функциональных» инструкций, общих для процессоров CISC и RISC, которые объединяют небольшую последовательность операций.

  • Почти неограниченная расширяемость. Хотя это и является целью RISC-V, но это создаёт фрагментированную, несовместимую экосистему, которой придётся управлять с особой осторожностью
  • Одна и та же инструкция (JALR) используется и для вызовов, и для возвратов и для косвенно-регистровых переходов (register-indirect branches), где требуется дополнительное декодирование для предсказания ветвей
    • Вызов: Rd = R1
    • Возврат: Rd = R0, Rs = R1
    • Косвенный переход: Rd = R0, RsR1
    • (Странный переход: RdR0, RdR1)
  • Кодирование с переменной длиной поля записи не самосинхронизируется (такое часто встречается — например, аналогичная проблема у x86 и Thumb-2, — но это вызывает различные проблемы как с реализацией, так и с безопасностью, например, возвратно-ориентированное программирование, то есть атаки ROP)
  • RV64I требует расширения знака для всех 32-разрядных значений. Это приводит к ненужному переключению или специальному размещению верхней половины регистров. Более оптимально использовать нулевое расширение (поскольку оно уменьшает число переключений и обычно его можно оптимизировать путём отслеживания «нулевого» бита, когда верхняя половина, как известно, равна нулю)
  • Умножение опционально. Хотя быстрые блоки перемножения занимают ненулевую площадь на крошечных реализациях, но можно широко использовать существующий ALU для многократных циклов умножения.
  • У LR/SC строгое требование к поступательному продвижению для ограниченного подмножества применений. Хотя это ограничение довольно жёсткое, оно потенциально создаёт некоторые проблемы для небольших реализаций (особенно без кэша)
    • Это кажется заменой инструкции CAS, см. комментарий ниже
  • Биты закрепления в памяти FP и режим округления находятся в одном регистре. Это требует сериализации канала FP, если выполняется операция RMW для изменения режима округления
  • Инструкции FP кодируются для 32, 64 и 128-битной точности, но не 16-битной (что значительно чаще встречается в аппаратном обеспечении, чем 128 бит)
    • Это можно легко исправить: кодирование 2'b10 бесплатно
    • Обновление: в версии 2.2 появился десятичный заполнитель, но нет заполнителя половинной точности. Уму непостижимо.
  • То, как значения FP представлены в файле регистра FP, не определено, но наблюдаемо (через load/store)
    • Авторы эмуляторов вас возненавидят
    • Миграция виртуальных машин может стать невозможной
    • Обновление: версия 2.2 требует более широких значений NaN-boxing

  • Отсутствуют коды условий, а вместо них используются инструкции compare-and-branch. Это не проблема сама по себе, но последствия неприятные:
    • Уменьшение пространства кодирования в условных переходах из-за необходимости кодирования одного или двух спецификаторов регистров
    • Нет условного выбора (полезно для очень непредсказуемых переходов)
    • Нет сложения с переносом / вычитания с переносом или заимствованием
    • (Обратите внимание, что это всё равно лучше, чем наборы команд, которые пишут флаги в GPR, а затем переходят на полученные флаги)
  • Высокоточные счётчики, по-видимому, требуются на уровне пользователя ISA. На практике, предоставление их приложениям является отличным вектором для атак по боковым каналам
  • Умножение и деление являются частью одного и того же расширения, и кажется, что если одно реализовано, то и другое тоже должно быть. Умножение значительно проще, чем деление, и распространено на большинстве процессоров, а деление нет
  • Нет атомарных инструкций в базе ISA. Всё более распространёнными становятся многоядерные микроконтроллеры, так что атомарные типы LL/SC совсем недорогие (для минимальной реализации одного процессора требуется только 1 бит состояния процессора)
  • LR/SC находятся в том же расширении, что и более сложные атомарные инструкции, что ограничивает гибкость для небольших реализаций
  • Общие атомарные инструкции (не LR/SC) не включают примитив CAS
    • Смысл в том, чтобы избежать необходимости в инструкции, которая читает пять регистров (Addr, CmpHi:CmpLo, SwapHi:SwapLo), но это, вероятно, наложит меньше накладных расходов на реализацию, чем гарантированное продвижение вперёд LR/SC, которое предоставляется в качестве замены
  • Предлагаются атомарные инструкции, которые работают на 32-разрядных и 64-разрядных величинах, но не 8-ми или 16-битных
  • Для RV32I нет способа передать значение DP FP между целым числом и файлами регистра FP, кроме как через память
  • Например, у 32-битной инструкция ADD в RV32I и 64-битной ADD в RVI64 одинаковые кодировки, а в RVI64 добавляется ещё и другая кодировка ADD.W. Это ненужное усложнение для процессора, который реализует обе инструкции — было бы предпочтительнее вместо этого добавить новую 64-битную кодировку.
  • Нет инструкции MOV. Алиас MV реализуется как MV rD, rS->ADDI rD, rS, 0. Оптимизацию MOV обычно выполняют высокопроизводительные процессоры (особенно нестандартные). Распознавание канонической MV в RISC-V требует немедленного осуществления операции OR в 12 бит
    • При отсутствии MOV инструкция MOV rD, rS, r0 фактически становится предпочтительнее канонической MOV, поскольку её легче декодировать, а в CPU обычно есть специальная логика для распознавания нулевого регистра

  • JAL тратит 5 бит на кодирование регистра связи, который всегда равен R1 (или R0 для переходов)
    • Это означает, что RV32I использует 21-битные смещения ветвей (branch displacement). Это недостаточно для больших приложений — например, веб-браузеров — без использования нескольких последовательностей команд и/или «островов ветвей» (branch islands)
    • Это хуже, чем в первой версии ISA!
  • Несмотря на большие усилия на равномерное кодирование, инструкции load/store кодируются по-разному (меняются регистр и непосредственные поля)
    • Видимо, ортогональность кодирования выходного регистра была предпочтительнее ортогональности кодирования двух сильно связанных инструкций. Этот выбор кажется немного странным, учитывая, что генерация адресов более критична по времени
  • Нет нагрузок со смещениями регистров (Rbase+Roffset) или индексов (Rbase+Rindex << Scale).
  • FENCE.I подразумевает полную синхронизацию кэша инструкций со всеми предыдущими хранилищами, с ограждением (fenced) или без него. Реализациям нужно или очищать весь I$ на ограждении, или выискивать D$ и накопительный буфер (store buffer)
  • В RV32I чтение 64-битных счётчиков требует двукратного чтения верхней половины, сравнения и ветвления в случае переноса между нижней и верхней половиной во время операции чтения
    • Обычно 32-разрядные ISA включают в себя инструкцию «чтение пары специальных регистров», чтобы избежать этой проблемы
  • Нет архитектурно определённого пространства hint-кодирования, которое выполнятся как NOP на текущих процессорах, но имеет некоторое поведение на самых современных CPU
    • Типичные примеры чистых «хинтов NOP» — такие вещи, как spinlock yield
    • На новых процессорах также реализованы более сложные хинты (с видимыми побочными эффектами на новых процессорах; например, инструкции проверки границ x86 кодируются в hint-пространстве, так что бинарники остаются обратно совместимыми)
Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть