Комментарии 11
Они 64-битную архитектуру предлагают для IoT, где люди каждый пикоджоуль считают?
Они предлагают архитектуру, которая может иметь совместимые на уровне ISA реализации с использованием только 32-битного, 64-битного или 128-битного режима адресации. Если конкретный тип систем (IoT) не требует/не может поддержать больше 32 бит, то от него не требуется реализовывать ненужные для него опциональные части.
вообще-то разрядность архитектуры и режимы адресации — разные вещи.
И тем не менее, практически всегда разрядность не больше ширины адреса. Было бы странно, если бы RISC-система, про которую утверждается, что она учла ошибки прошлого, имела 64-битные регистры, но 32-битные адреса. Если посмотреть хотя бы в легенду таблицы 4 оригинальной статьи, то можно увидеть, что обязательной базой является именно RV32I и её 32-битные по ширине регистры.
Table 4. RISC-V Integer Base Instructions (RV32I/64I/128I) and instruction formats. The base has 40 classic RISC
integer instructions, plus 10 miscellaneous instructions for synchronization, system calls, and counters. All RISC-V
implementations must include these base instructions, and we call the 32-bit version RV32I. The 64-bit and 128-bit
versions (RV64I and RV128I) expand all the registers to those widths and add 10 instructions for new data transfer
and shift instructions of the wider formats. It also shows the optional compressed instruction extension: those 12
instructions with Cx formats, which are 16 bits long. There are other optional instruction extensions defined so far:
Multiply-Divide, SP/DP/QP Floating Point, and Atomic. To learn more, see www.riscv.org
Table 4. RISC-V Integer Base Instructions (RV32I/64I/128I) and instruction formats. The base has 40 classic RISC
integer instructions, plus 10 miscellaneous instructions for synchronization, system calls, and counters. All RISC-V
implementations must include these base instructions, and we call the 32-bit version RV32I. The 64-bit and 128-bit
versions (RV64I and RV128I) expand all the registers to those widths and add 10 instructions for new data transfer
and shift instructions of the wider formats. It also shows the optional compressed instruction extension: those 12
instructions with Cx formats, which are 16 bits long. There are other optional instruction extensions defined so far:
Multiply-Divide, SP/DP/QP Floating Point, and Atomic. To learn more, see www.riscv.org
Ну я лично знаю как минимум одну широко известную в узких кругах 32-битную архитектуру, где можно конфигурировать ширину шины адреса в пределах от 16 от 32 бит.
Что касается RISC-V, то из вашей ссылки действительно следует, что разрядность архитектуры будет зависеть от реализации, что само по себе звучит как бред. Господа в очередной раз пытаются усидеть на трех стульях одновременно, создав универсальную архитектуру на все случаи жизни. По логике, за ней должна последовать универсальная ОС, покрывающая весь спектр от RTOS до мэйнфрэймовых операционок.
Что касается RISC-V, то из вашей ссылки действительно следует, что разрядность архитектуры будет зависеть от реализации, что само по себе звучит как бред. Господа в очередной раз пытаются усидеть на трех стульях одновременно, создав универсальную архитектуру на все случаи жизни. По логике, за ней должна последовать универсальная ОС, покрывающая весь спектр от RTOS до мэйнфрэймовых операционок.
>> Включение излишнего: встроенный сдвиг в инструкциях ARM и регистровые окна SPARC
Встроенный сдвиг и условное выполнение позволяет сильно сократить количество команд во многих случаях — сиё и есть та самая жемчужина ARM архитектуры.
В крошечных реализациях ARM теоретически возможно использовать основное ALU для полноценного вычисления адресов adr = X+Y [сдвиг] Z, вместо специализированного AGU.
Проблема сдвигов и условного выполнения лишь в том, что они несколько усложняют разработку высокопроизводительных OoO ядер и занимают лишние биты в коде операции когда не используются. В этот сегмент нацелена ARMv8 и переработана под новые реалии.
Что же касается Dhrystone, к общей убогости этого «теста» добавляется тот факт, что на 64битах он выполняется вдвое быстрее, т.е. сравнение некорректно.
В остальном же данное начинание можно только поприветствовать.
Встроенный сдвиг и условное выполнение позволяет сильно сократить количество команд во многих случаях — сиё и есть та самая жемчужина ARM архитектуры.
В крошечных реализациях ARM теоретически возможно использовать основное ALU для полноценного вычисления адресов adr = X+Y [сдвиг] Z, вместо специализированного AGU.
Проблема сдвигов и условного выполнения лишь в том, что они несколько усложняют разработку высокопроизводительных OoO ядер и занимают лишние биты в коде операции когда не используются. В этот сегмент нацелена ARMv8 и переработана под новые реалии.
Что же касается Dhrystone, к общей убогости этого «теста» добавляется тот факт, что на 64битах он выполняется вдвое быстрее, т.е. сравнение некорректно.
В остальном же данное начинание можно только поприветствовать.
>> Включение излишнего: встроенный сдвиг в инструкциях ARM и регистровые окна SPARC
У меня наоборот чувства — за регистровые окна SPARC обидно. Их идея мне кажется здравой.
> Dhrystone, к общей убогости этого «теста»
Согласен, благо уже существуют и получше наборы тестов. Пора бы и забыть про Dhrystone, по крайней мере перестать им мериться.
У меня наоборот чувства — за регистровые окна SPARC обидно. Их идея мне кажется здравой.
> Dhrystone, к общей убогости этого «теста»
Согласен, благо уже существуют и получше наборы тестов. Пора бы и забыть про Dhrystone, по крайней мере перестать им мериться.
Регистровые окна живут и здравствуют. И очень популярны во встроенных системах, критичных ко времени обработки прерываний.
Да, регистровые окна увеличивают быстродействие программ на старых Спарках v8 с их простенькой подсистемой памяти, по сравнению с «плоским» режимом.
Современные не представилась возможность протестировать — не знаю как там дела.
Когда заканчиваются регистры вызывается прерывание, которое сохраняет все регистры из одного окна и освобождает его, что довольно не быстро. Также setjmp() по-идее будет медленным, так как нужно сохранить все окна, либо игнорировать неконсистентные данные в стеке.
Собственно регистровые окна появились в RISC-I, который разрабатывал тот же самый человек (David Patterson).
Так что RISC-V это некое переосмысление.
Современные не представилась возможность протестировать — не знаю как там дела.
Когда заканчиваются регистры вызывается прерывание, которое сохраняет все регистры из одного окна и освобождает его, что довольно не быстро. Также setjmp() по-идее будет медленным, так как нужно сохранить все окна, либо игнорировать неконсистентные данные в стеке.
Собственно регистровые окна появились в RISC-I, который разрабатывал тот же самый человек (David Patterson).
Так что RISC-V это некое переосмысление.
Это просто божественно, я почти ощущаю что скоро будет аппаратный рай)
Кто нибудь FPGA-синтез пробовал провести?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наборы команд должны быть свободны: доводы за RISC-V