Комментарии 11
Оно в обязательном порядке должно выполнять все команды, которые использовались в архитектуре RISC V 32-битного исполнения
Нифига подобного. Если тут речь про 32-битный режим, то он в 64-битном ядре опциональный, например t-head c906 не имеют такогово. Если речь про кодировку 32-битных операций в 64-битном режиме, то они не совпадают с кодировкой таких же по смысле 32-битных операций в 32-битном режиме (или в чисто 32-битном ядре). Ввиду чего отквоченное утверждение получается ниачём.
О кодировке вообще речь не идет, это не существенно, кроме того, этот тезис не соответствует действительности. Нет специальных кодировок для RV32 и для команд из набора RV32 в 64-битном исполнении. Насчет необязательности вопрос интересный. Возьмем, к примеру, группу команд конвертации чисел с плавающей точкой (FCVT.S.D, FCVT.D.S) перевод данных из двойной точности в одинарную и наоборот. Нигде не сказано, что эти команды не обязательны.
С другой стороны, каждый может исполнять открытую (не только в плане владения лицензиями, но и к модификациям тоже!) архитектуру по-своему, есть даже рекомендации на этот счет. В общем, вольному воля.
Нет специальных кодировок для RV32 и для команд из набора RV32 в 64-битном исполнении.
Насколько понимаю, описанные в RV32I команды в 64битном режиме обрабатывают 64битные значения, для обработки 32битных значений в 64битном режиме есть отдельные кодировки (ADDIW и т.п.).
группу команд конвертации чисел с плавающей точкой
Плавающая точка вообще не обязательна )
Про кодировки уже пояснили, я ещё раз поясню что 64-битный процессор МОЖЕТ перейти в 32-битный режим (где обычные команды будут выполнять 32-битные операции, адресовать память 32 битами и исчезнут команды opW). Может, если в нём есть таковая поддержка, и соответствующий бит в CSR можно переключить. А если поддержки нет -- то он работает только в 64-битном режиме.
Это плохие предложения.
Первый вариант - это по сути предложение сделать Гипертрединг в 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 сам по себе вещь достаточно спорная. Резюмируя, пользы от такого расширения будет крайне мало скорее всего.
В общем, да, сходство есть. Но в данном случае предлагается конфигурационное изменение ядра без ввода дополнительных команд. Например, 64-битное ядро после реконфигурации распадается на два 32-битных ядра RV, для которых используется система команд RV32 и один дешифратор операций, понятно, с некоторыми модификациями.
Вопрос о пользе дискуссионный. Тут, кроме наличия аппаратных возможностей, многое зависит от других факторов, в первую очередь, соответствующего софта.
Но в данном случае предлагается конфигурационное изменение ядра без ввода дополнительных команд. Например, 64-битное ядро после реконфигурации распадается на два 32-битных ядра RV
Вы же сами признаёте, что нет изменений в ISET. Причём тогда здесь архитектура RISC-V? Ну сделайте чип с такой фичей, для этого не надо ничего менять в системе команд. Другой разговор, что как я написал выше, мне сложно представить, зачем такая фича нужна. Но, возможно, ваши маркетологи знают ответ на данный вопрос (хотя сомневаюсь)
Вопрос о пользе дискуссионный. Тут, кроме наличия аппаратных возможностей, многое зависит от других факторов, в первую очередь, соответствующего софта
Такого софта нет и его придётся пилить. Но я изначально рассуждал в позитивном ключе, что софт у вас магическим образом появится. Проблема куда глубже, и она описана в моём предыдущем комментарии - эта фича в теории может понадобиться только на слабых ядрах без V расширения. На практике выгоднее поставить 2-way superscalar 32-битное ядро и получить всё то же самое, только практически автоматом. И получается, что спектр полезности сужается до каких-то микроскопических случаев, которых я даже сходу и придумать не могу. Совсем не просто так в RISC-V комитете дропнули P-extension
В чем Вы правы, так это в том, что подобную процедуру можно применить практически к любому ядру. А почему именно к RV - потому, что все остальное народ уже мало интересует..
А дропнули, по Вашему выражению, это расширение скорее всего по причине того, что система команд для него очень тяжеловесная. Если ее присовокупить к стандартной, получится никому не нужный монстр. Чисто с философской точки зрения, я думаю, что эти расширения и станут могильщиками архитектуры.RV. Впрочем, недостатки - почти всегда оборотная сторона достоинств. Но это будет еще не скоро. У нас же, предлагается способ реализации, который практически не нагружает систему команд.
Ну в тех же armv7-m есть недо-SIMD с обработкой 4 байтов или 2 полувордов в одном 32-битном регистре. Так что видимо польза для лоу-энда и эмбеддеда есть.
Мысли о доработке архитектуры RISC V