RISC-V
https://www.csl.cornell.edu/courses/ece4750/handouts/ece4750-tinyrv-isa.pdf
Страница 5 содержит объяснение, как разбирать непосредственные операнды в разных форматах. Вроде, все пять форматов рассмотрены.
Если вам надо интересной глупости ( Read more... )
Страница 5 содержит объяснение, как разбирать непосредственные операнды в разных форматах. Вроде, все пять форматов рассмотрены.
Если вам надо интересной глупости ( Read more... )
На длинный пост длинный ответ...
Реализация с 12 бит имеет вполне очевидное объяснение, и, как ни странно, проистекает из самой идеи RISC-V, как открытой архитектуры. Идея заключается в том, что RISC-V задумывалась, как модульная расширяемая архитектура, а значит, в кодировке инструкций должно оставаться достаточно место для добавления новых инструкций. При большем значении IMM-части просто остается слишком мало места под кодирование опкода, что упоминается, как один из недостатков MIPS.
Исторически так сложилось, что сейчас широко используются 8-битные байты и 32-битные инструкции в RISC-процессорах. Могло быть и по другому, например, 6-битные байты и 48-битные инструкции (но инфраструктура индустрии сейчас под это не заточена от слова совсем)...
Если принято решение, что инструкция кодируется 32-битами, то в команде работы с непосредственными значениями мы имеем такие части: опкод, регистр источника, регистр назначения и непосредственное значение. Т.к. запланировано 32 регистра, то номер регистра кодируется 5-ю битами. В случае с RISC-V прикинули и решили выделить: 7 бит на кодирование группы длинных (32-бит и более) и коротких (16-битных) инструкций. Группы длинных инструкций -- табличка 4 строки на 8 столбцов (можно найти в спецификации). Итого, на непосредственное значение и кодирование инструкции в группе остается 32 - 7 - 5 - 5 = 15 бит. Так что ни о каких 16-битах непосредственного значения в кодировании речи быть не может.
Далее, выбор 12 бит -- это по сути, результат согласования разных форматов кодирования. Потому что удалось сделать формат U для загрузки верхнего значения из 20 бит (32 - 7 - 5), и сделать поле func3 размером 3 бита для типа операции.
Reply
У RISC-V практически бесконечное пространство команд, у него длина команды переменная. То, что нельзя было делать в MIPS, можно и нужно было делать в RISC-V, то, что MIPS сделал с запасом (более, чем 13-тибитный непосредственный операнд, расширяемый по разному в зависимости от команды в том числе), надо было повторять в RISC-V.
Да, малоизвестный современным разработчикам факт - у нульадресной (стековой) машины плотность кода очень высока. Те самые 6 битов на инструкцию, а то и меньше можно (GA144, там 5). Почему RISC-V не пошёл путём нульадресной машины?
Вот то-то и оно.
Reply
> У RISC-V практически бесконечное пространство команд, у него длина команды переменная
Вы не путайте потенциал развития, заложенный в схему кодирования и базовую ISA. В базовой ISA команды строго 32-битные и ее цель обеспечить простой набор команд, с простой реализацией FPGA/ASIC.
Сама по себе спецификация RISC-V - это не сухой документ, констатирующий факт. Это документ с множеством ссылок, объясняющий цели, намерения, ссылающийся на опыт других архитектур, проектов и т.п. В начальной разработке спецификации архитекторами были в т.ч. Девид Паттерсон и Крсте Асанович, уж они-то в курсе, что и как было сделано в MIPS.
Reply
Вот насчёт простоты у меня вопросов полно. Начиная с двух пар совершенно идентичных форматов, которые, тем не менее, разные.
У меня там вопрос был: "Почему RISC-V не пошёл путём нульадресной машины в сжатом наборе команд?"
Что по этому поводу говорят Крсте и Девид?
Reply
> Начиная с двух пар совершенно идентичных форматов, которые, тем не менее, разные.
Так объяснение же дано, что бы можно было еще сильнее упростить декодер. Лично с моим жизненным опытом это совпадает. С вашим, видимо, не совпадает. Так же, в ревизии 2011 года общими в формате были были только биты адресов регистров, а IMM выглядели "красиво". Во второй ревизии RISC-V уже сделали вариант, более оптимальный для синтеза. Вроде, понятно, что такая доработка была не просто так.
> У меня там вопрос был: "Почему RISC-V не пошёл путём нульадресной машины в сжатом наборе команд?"
Уточните вопрос. Вы имеете в виду, что нужно создать отдельную ISA под сжатые инструкции? Опять же, это противоречит подходам и целям, которые ставились для сжатых инструкций. Стандартные сжатые инструкции не вводят какие-то новые инструкции, а основаны на существующих 32-битных.
Reply
"Из этого с очевидностью следует" меня удовлетворить не может.
Цифр нет.
Чего они добились-то?
> Стандартные сжатые инструкции не вводят какие-то новые инструкции, а основаны на существующих 32-битных.
https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/notebooks/RISCV/RISCV_CARD.pdf
Там есть и форматы сжатых инструкций, третья страница. Ничего они не основаны на 32-хбитных. Например, CI type имеет funct3 не там, где funct3 у 32-хбитных.
Во всём документе нет ни слова про энтропию, про набор программ для её вычисления, про компиляторы, от качества которых многое зависит.
Здесь я опять вижу, что "мы сделали вот так, вам теперь с этим жить."
Reply
> "Из этого с очевидностью следует" меня удовлетворить не может.
...
...
Видимо, что бы понять, нужно выполнить задание из книги Харрисов.
Reply
Большое спасибо за беседу.
Reply
> Ничего они не основаны на 32-хбитных.
Идея сжатых инструкций в RISC-V в рамках подхода упрощения декодера - что бы любой 16-битной инструкции соответствовала 32-битная. Тогда достаточно сделать блок расширения 16-битной инструкции в 32-битную без какой-либо сложной логики (и с учетом изменения PC на 2, а не на 4).
> Во всём документе нет ни слова про энтропию
Есть живые доклады на эту тему, есть слайды, есть статьи. Навскидку:
https://people.eecs.berkeley.edu/~krste/papers/waterman-ms.pdf
people.eecs.berkeley.edu
Reply
Leave a comment