Мысли о доработке архитектуры RISC V
Архитектура 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).
Рис. 2
Рис. 3
В итоге 64-битный процессор может быть представлен в виде пары 32-битных ядер, которые могут работать в режимах «одна команда, много данных — SIMD» или «много команд-много данных — MIMD».
Режим SIMD RISCV-64
Режим MIMD RISCV-64
Конечно, это упрощенное представление предлагаемого подхода. Операция умножения раскладывается на 32-битные операнды несколько более сложным способом, а операция деления 64-битного числа вообще не может быть представлена в виде операций над 32-битными числами.
Подход может быть продолжен до своего логического конца — то есть до обработки 8-битных данных. Отметим при этом, что аппаратные доработки требуются очень небольшие.
