Комментарии 41
Тоже касается и загрузки — всякие uboot/uefi умеют в RISC-V — вполне себе стандарты (в зависимости от того что за девайс).
У меня на столе прямо сейчас лежат два ARM-одноплатника разных производителей, которые используют uboot, но тем не менее они не способны даже начать грузить систему, если им поменять флешки.
Если уж на то пошло, то и сборки UEFI тоже так же себя будут вести на любой архитектуре (исключением, может быть, будет payload для какого-нибудь coreboot). Другое дело, что у uboot нет стандартизированного интерфейса взаимодействия с ОС, поэтому они вынуждены имитировать UEFI.
Не надо верить всему, что пишут в интернете: https://twitter.com/andreif7/status/1334862926218457090
CoreMark — это довольно примитивный набор тестов, предназначенный, в первую очередь, для оценки микроконтроллеров, поэтому не делает никаких попыток оценки производительности внеочередного и спекулятивного исполнения, качества бранч-предиктора, скорости и размера кэшей, задержек и пропускной способности памяти — в общем всего того, что делает современные процессоры во много раз быстрее какого-нибудь P4 на той же частоте.
Когда я сам по диогонали пробежался по принципам построения ISA RISC-V то обратил внимание по сути только на отсутствие регистра состояний — что показалось очень правильным для параллельного вычисления. Но оказалось, что две довольно важные вещи (сжатие и fusion) — как-то не прочувствовал.
И собственно теперь понятно на чем зиждется заявления о меньших ватах/операцию для RISC-V: меньше микрокоманд для выполнения тех же действий — меньше и энергии потребуется.
А можно небольшой ликбез: почему всё это не может делать компилятор?
Понятно, что когда конкретный процессор неизвестен и нужен один универсальный бинарник, то такие вещи делать сложно.
Но ведь можно компилять под определенный процессор и сразу в микрокоманды.
Это VLIW. Попытки предпринималось неоднократно, но не взлетело. Слишком сложный компилятор, низкая плотность кода (больше обращений к памяти), плюс, процессор при реордеринге и спекулятивном выполнении имеет рантайм-информацию, а компилятор -нет.
Собственно, пока это все гос заказ — вообще трудно говорить о «взлете» — даже если оно не летит, тему могут тянуть бюджетные деньгами очень долго.
ЗЫ Хотя не могу не согласиться что оно все-таки кое как летает, судя по отзывам и обзорам, хотя и не очень высоко летает.
Всегда в выигрыше тот, кто посмотрит на сделанные ранее архитектуры, сделает хороший системный анализ, выберет сильные стороны, отбросит слабые. Но другие «не гениальные » архитектуры уже приносят пользу, а у этой еще все впереди. Также не пойму о какой простоте системы команд пишет автор. Возможно статья писалась когда была доступна только версия команд R32I. Нескончаемым потоком пишутся все новые расширения для этой архитектуры :) Какой бы ни была эта архитектура, лучшие процессоры RISC-V сделают те же разработчики которые сейчас делают лучшие x86, ARM,MIPS и т.д. Но несомненная польза RISC-V в том, что попрактиковаться в проектировании этой архитектуры процессора может каждый. И ничего ему за это не будет :)
Хоть кто-нибудь смог реально сделать fusion в железе RISC-V? Пока нет такого железа, рассказы про то, что это преимущество, ничего не стоят.
Post increment как раз эффективней пилить на 2 микрооперации. В этом случае на out-of-order superscalar инкремент не будет дожидаться окончания лоада. А лоад может зависнуть на много сотен тактов в случае cache miss. А вот индексация массива по регистру лучше делается одной микроопераций: лоад всё равно нельзя запустить до того, как будет вычислен адрес. А адресация (base + offset) уже есть, то есть в address generation unit есть сумматор. В железе не слишком сложно завести туда данные из регистра вместо immediate value из опкода. В RISC-V эту задачу должен решить fusion, но пока не видно железа, которое это умеет. На моей прошлой работе такое пытались сделать (не для RISC-V, для собственной архитектуры), но это не заводились на частотах выше 350 МГц
.
Именно из-за этого RISV-C не имеет и регистров состояния, ведь они создают зависимости между командами.
Я бы скзаал, что склейка комманд это как раз и есть зависимость. Фактически это проброс имён регистров в следующие комманды (если обе комманды за 1 такт, а не просто экономим на передаче операндов, то это вообще CISCовый треш и разбазаривание транзисторов, которые можно было пустить ещё на 1 конвеер), то же самое можно было бы реализовать, если, например, кешировать последние три имени использововашихся регистров и в последующих коммандах просто битиком отмечать, что операнды берём из кеша имён регистров.
Единственное, чего они действительно добились, это — опциональность такого подхода и это же огромный минус: может работать, а может не работать, может склеиться, а может не склеиться, программист тоже мог учестЬ, а мог не учесть. Я бы сказал, что очень спорное решение, можно было придумать что-нибудь более явное и простое, типа кеша.
ADD a0, a0, a1; a0 ← a0 + a1
C.LW a0, a0, 0; a0 ← [a0 + 0]
Почему нельзя
LW a0, a0, a1
?
Сия фича была предложена в архитектуру RISC-V только в 2016, и, на сколько я знаю, нигде ещё не была реализована и не понятна когда и где будет. Так что вся эта хвалебная ода, это сравнение некоторого теоретического процессора с неизвестными характеристиками с реальными и работающими.
add a3,a5,a1
mv a0,a3
sltu a0,a0,a5
add a4,a6,a2
add a5,a0,a4
Интересно, fusion здесь тоже применяют?
В MIPS примерно то же самое (https://stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly). Это наводит на мысль о том, что RISC-V instruction set по большей части содрали с MIPS, не проводя какого-то анализа других архитектур.
Про отсутствие анализа других архитектур, мягко говоря вздор. Даже на русский есть переводы анализа архитектур: Паттерсон «Компьютерная архитектура. Количественный подход. Руководство».
Это, простите, не анализ а научно-популярная литература для широкого круга интересующихся. Написано, правда, хорошо, этого не отнять.
Нормальный анализ делается с применением потактовых симуляторов, и приводит к тому, что в архитектуре появляются инструкции, которые в RISC-V не представлены. В понимании авторов RISC-V, это должен обрабатывать instruction fusion. Но покажите мне железо, в котором это реализовано.
В out-of-order superscalar это не настолько важно: в процессоре будет буфур декорированных инструкций, из которого процессор будет брать готовые для исполнения команды. И по большому счёту не очень важно, в каком порядке они идут в коде программы. Вот в in-order superscalar важнее, чтобы компилятор правильно расставил инструкции. Для этого в компиляторах планировщики пишут. В out-of-order компилятор тоже более-менее оптимально пытается расставить инструкции, но это нужно скорее для того, чтобы декодирование не тормозило.
А почему не эти?
C.SLLI a1, 2; a1 ← a1 << 2
C.ADD a0, a1; a0 ← a0 + a1
Гениальность микропроцессоров RISC-V