Архитектура RISC V (читается как «риск файв») существует и развивается более полутора десятилетий. Участиев развитии этой архитектуры принимают тысячи фирм по всему миру.
На очередном круглом столе российского Альянса RISC V в НИУ «МЭИ» мы — компания «Аквариус» — предложили свою идею по доработке. Выносим ее на суд сообщества.
Обычно компании‑основоположники архитектур закрывают свои системы команд (ISA — instruction set architecture — архитектура системы команд, проще — система команд) от сторонних разработчиков патентными ограничениями, а иногда и судебными преследованиями. Сами они, как правило, развивают свою архитектуру не очень охотно.
Стимулом для нововведений часто становится истечение срока лицензионной защиты. ISA дорабатывается, чтобы снова закрыть доступ со стороны к правкам или самостоятельному повторению всей архитектуры. Также толчок в этом направлении может дать требование увеличить разрядность обрабатываемых данных — со временем оно становится очевидным. Как ни странно, сюда же можно отнести и требование уменьшить разрядность. Классическим примером можно считать архитектуру MIPS. Первоначально 32-битная, в конце концов она стала 64-битной с поддержкой 16 ‑разрядной обработки данных.
Почти такой же танец мы увидели и в исполнении RISC V. Но тут есть важные особенности.
Если говорить о других архитектурах, их исходный вариант никак не подразумевал дальнейшее развитие — оно ничем не обеспечивалось. А вот RISC V разрабатывалась с учетом того, что она будет развиваться, в нее были заложены такие возможности. А главное — она изначально была открытой, то есть доступной для усовершенствования.
Этими возможностями в мире стали пользоваться очень интенсивно. Следуя новомодным тенденциям, можно заявить, что RISC V — это целая Вселенная. Изначально эта архитектура представляла собой компактное ядро с небольшим набором команд. А сейчас ядро осталось то же, но у него появилось очень большое число расширений — их количество уже подходит четырем десяткам. Как и положено любой приличной Вселенной, мир RISC V непрерывно расширяется. Это экстенсивный способ развития, который заключается в постоянном включении новых возможностей в стандарт архитектуры.
Такое развитие можно представить следующей иллюстрацией (Рис 1).
Рис. 1.
В развитии RISC V, разумеется, принимают участие и российские организации, объединенные в «Альянс RISC V» — сообщество независимых разработчиков вычислительной техники и ПО на основе этой архитектуры. Альянс ведет активную деятельность и со своей стороны также постоянно предлагает улучшения. Например, на последнем (проходившем в ноябре 2024 года) Круглом столе «Аквариус» предложил направление развития архитектуры RISC V, которое можно условно назвать интенсивным, поскольку оно осуществляется за счет более полного задействования внутренних аппаратных ресурсов.
В чем заключается идея?
Представим себе ядро процессора RISC V в 64-разрядном исполнении. Оно в обязательном порядке должно выполнять все команды, которые использовались в архитектуре RISC V 32-битного исполнения — если мы хотим использовать 64-битное ядро в качестве 32-битного, для этого есть все возможности. Ясно, что в этом режиме очень большая часть 64-битного ядра будет простаивать, поскольку 64-разрядные регистры используются в качестве 32-битных, причем старшие половинки регистров задействуются только для хранения расширения знака числа. Аналогично и в АЛУ: его младшая половина используется производительно, а старшая — только для обработки расширения знака, что, вообще говоря, и не требуется (рис.2 и рис. 3).
В итоге 64-битный процессор может быть представлен в виде пары 32-битных ядер, которые могут работать в режимах «одна команда, много данных — SIMD» или «много команд‑много данных — MIMD».
Режим SIMD RISCV-64
Режим MIMD RISCV-64
Конечно, это упрощенное представление предлагаемого подхода. Операция умножения раскладывается на 32-битные операнды несколько более сложным способом, а операция деления 64-битного числа вообще не может быть представлена в виде операций над 32-битными числами.
Подход может быть продолжен до своего логического конца — то есть до обработки 8-битных данных. Отметим при этом, что аппаратные доработки требуются очень небольшие.
Комментарии (9)
Armmaster
11.12.2024 14:24Это плохие предложения.
Первый вариант - это по сути предложение сделать Гипертрединг в 64-битном ядре, причем он работает только 32-битном режиме. Зачем такая хрень нужна мне сложно представить. Но в любом случае, это не архитектурная вещь, а микроархитектурная, и к системе команд RISC-V напрямую не относится..
Второй вариант - это попытка сделать эрзац SIMD расширение. По сути, это реинкарнация P-расширения RISC-V про которое в спеке написано следующее:
"Discussions at the 5th RISC-V workshop indicated a desire to drop this packed-SIMD
proposal for floating-point registers in favor of standardizing on the V extension for large
floating-point SIMD operations. However, there was interest in packed-SIMD fixed-point
operations for use in the integer registers of small RISC-V implementations. A task group
is working to define the new P extension."Для больших ядер это и правда нафиг не нужно, если есть V-extension. А для маленьких как правило simd сам по себе вещь достаточно спорная. Резюмируя, пользы от такого расширения будет крайне мало скорее всего.
vero2011 Автор
11.12.2024 14:24В общем, да, сходство есть. Но в данном случае предлагается конфигурационное изменение ядра без ввода дополнительных команд. Например, 64-битное ядро после реконфигурации распадается на два 32-битных ядра RV, для которых используется система команд RV32 и один дешифратор операций, понятно, с некоторыми модификациями.
Вопрос о пользе дискуссионный. Тут, кроме наличия аппаратных возможностей, многое зависит от других факторов, в первую очередь, соответствующего софта.
Armmaster
11.12.2024 14:24Но в данном случае предлагается конфигурационное изменение ядра без ввода дополнительных команд. Например, 64-битное ядро после реконфигурации распадается на два 32-битных ядра RV
Вы же сами признаёте, что нет изменений в ISET. Причём тогда здесь архитектура RISC-V? Ну сделайте чип с такой фичей, для этого не надо ничего менять в системе команд. Другой разговор, что как я написал выше, мне сложно представить, зачем такая фича нужна. Но, возможно, ваши маркетологи знают ответ на данный вопрос (хотя сомневаюсь)
Вопрос о пользе дискуссионный. Тут, кроме наличия аппаратных возможностей, многое зависит от других факторов, в первую очередь, соответствующего софта
Такого софта нет и его придётся пилить. Но я изначально рассуждал в позитивном ключе, что софт у вас магическим образом появится. Проблема куда глубже, и она описана в моём предыдущем комментарии - эта фича в теории может понадобиться только на слабых ядрах без V расширения. На практике выгоднее поставить 2-way superscalar 32-битное ядро и получить всё то же самое, только практически автоматом. И получается, что спектр полезности сужается до каких-то микроскопических случаев, которых я даже сходу и придумать не могу. Совсем не просто так в RISC-V комитете дропнули P-extension
mpa4b
11.12.2024 14:24Ну в тех же armv7-m есть недо-SIMD с обработкой 4 байтов или 2 полувордов в одном 32-битном регистре. Так что видимо польза для лоу-энда и эмбеддеда есть.
unreal_undead2
11.12.2024 14:24Добавить такие инструкции, возможно, имеет смысл. Но предлагаемое разбиение 64битного ядра на два логических 32битных - это несколько другое.
mpa4b
Нифига подобного. Если тут речь про 32-битный режим, то он в 64-битном ядре опциональный, например t-head c906 не имеют такогово. Если речь про кодировку 32-битных операций в 64-битном режиме, то они не совпадают с кодировкой таких же по смысле 32-битных операций в 32-битном режиме (или в чисто 32-битном ядре). Ввиду чего отквоченное утверждение получается ниачём.
vero2011 Автор
О кодировке вообще речь не идет, это не существенно, кроме того, этот тезис не соответствует действительности. Нет специальных кодировок для RV32 и для команд из набора RV32 в 64-битном исполнении. Насчет необязательности вопрос интересный. Возьмем, к примеру, группу команд конвертации чисел с плавающей точкой (FCVT.S.D, FCVT.D.S) перевод данных из двойной точности в одинарную и наоборот. Нигде не сказано, что эти команды не обязательны.
С другой стороны, каждый может исполнять открытую (не только в плане владения лицензиями, но и к модификациям тоже!) архитектуру по-своему, есть даже рекомендации на этот счет. В общем, вольному воля.
unreal_undead2
Насколько понимаю, описанные в RV32I команды в 64битном режиме обрабатывают 64битные значения, для обработки 32битных значений в 64битном режиме есть отдельные кодировки (ADDIW и т.п.).
Плавающая точка вообще не обязательна )
mpa4b
Про кодировки уже пояснили, я ещё раз поясню что 64-битный процессор МОЖЕТ перейти в 32-битный режим (где обычные команды будут выполнять 32-битные операции, адресовать память 32 битами и исчезнут команды opW). Может, если в нём есть таковая поддержка, и соответствующий бит в CSR можно переключить. А если поддержки нет -- то он работает только в 64-битном режиме.