Как стать автором
Обновить

Комментарии 41

НЛО прилетело и опубликовало эту надпись здесь
Переферия — все там же и также: ей почти пофигу какая там ISA в процессоре.

Тоже касается и загрузки — всякие uboot/uefi умеют в RISC-V — вполне себе стандарты (в зависимости от того что за девайс).
НЛО прилетело и опубликовало эту надпись здесь
У меня на столе прямо сейчас лежат два ARM-одноплатника разных производителей, которые используют uboot, но тем не менее они не способны даже начать грузить систему, если им поменять флешки.


Если уж на то пошло, то и сборки UEFI тоже так же себя будут вести на любой архитектуре (исключением, может быть, будет payload для какого-нибудь coreboot). Другое дело, что у uboot нет стандартизированного интерфейса взаимодействия с ОС, поэтому они вынуждены имитировать UEFI.
Вот, например, из последнего: arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt. Утверждают, что обходят все популярные десктопные процессоры по производительности на ватт, да и сама производительность уже не так плоха, хотя пока не было бенчмарков на реальных задачах.

Не надо верить всему, что пишут в интернете: https://twitter.com/andreif7/status/1334862926218457090


CoreMark — это довольно примитивный набор тестов, предназначенный, в первую очередь, для оценки микроконтроллеров, поэтому не делает никаких попыток оценки производительности внеочередного и спекулятивного исполнения, качества бранч-предиктора, скорости и размера кэшей, задержек и пропускной способности памяти — в общем всего того, что делает современные процессоры во много раз быстрее какого-нибудь P4 на той же частоте.

У ARM есть спецификация EBBR года этак с 2017. То, что еще не все ее осилили — проблемы неосиливших.

"У ARM есть спецификация EBBR года этак с 2017. То, что еще не все ее осилили — проблемы неосиливших."
Поясните пожалуйста!

Спасибо за статью.

Когда я сам по диогонали пробежался по принципам построения ISA RISC-V то обратил внимание по сути только на отсутствие регистра состояний — что показалось очень правильным для параллельного вычисления. Но оказалось, что две довольно важные вещи (сжатие и fusion) — как-то не прочувствовал.

И собственно теперь понятно на чем зиждется заявления о меньших ватах/операцию для RISC-V: меньше микрокоманд для выполнения тех же действий — меньше и энергии потребуется.

А можно небольшой ликбез: почему всё это не может делать компилятор?
Понятно, что когда конкретный процессор неизвестен и нужен один универсальный бинарник, то такие вещи делать сложно.
Но ведь можно компилять под определенный процессор и сразу в микрокоманды.

Это VLIW. Попытки предпринималось неоднократно, но не взлетело. Слишком сложный компилятор, низкая плотность кода (больше обращений к памяти), плюс, процессор при реордеринге и спекулятивном выполнении имеет рантайм-информацию, а компилятор -нет.

Еще очень рано ИМХО судить взлетело ли оно или нет.

Собственно, пока это все гос заказ — вообще трудно говорить о «взлете» — даже если оно не летит, тему могут тянуть бюджетные деньгами очень долго.

ЗЫ Хотя не могу не согласиться что оно все-таки кое как летает, судя по отзывам и обзорам, хотя и не очень высоко летает.
На свободном рынке нет, негосударственных заказов нет, даже в апстриме того же линукса нет. Что-то это мало похоже на «взлетело».
НЛО прилетело и опубликовало эту надпись здесь
RISC-V конечно интересный проект, но говорить о какой-то гениальности я бы не стал.
Всегда в выигрыше тот, кто посмотрит на сделанные ранее архитектуры, сделает хороший системный анализ, выберет сильные стороны, отбросит слабые. Но другие «не гениальные » архитектуры уже приносят пользу, а у этой еще все впереди. Также не пойму о какой простоте системы команд пишет автор. Возможно статья писалась когда была доступна только версия команд R32I. Нескончаемым потоком пишутся все новые расширения для этой архитектуры :) Какой бы ни была эта архитектура, лучшие процессоры RISC-V сделают те же разработчики которые сейчас делают лучшие x86, ARM,MIPS и т.д. Но несомненная польза RISC-V в том, что попрактиковаться в проектировании этой архитектуры процессора может каждый. И ничего ему за это не будет :)

Хоть кто-нибудь смог реально сделать fusion в железе RISC-V? Пока нет такого железа, рассказы про то, что это преимущество, ничего не стоят.

То, что в ARM есть пост-инкрементная адресация, в Р5 будет две команды. Автор объясняет, что пост-инкрементная адресация это очень сложно и лучше две раздельные команды. Вы их можете скомпрессировать(если получится), но внутри процессора вы можете эти две простые команды превратить в одну ARM-команду, чтобы выполнить её за один такт. Ведь это же проще чем декодировать одну сложную команду. Но вам нужно позаботится о том, чтобы компилятор вам эти команды расположил рядом, а лучше вообще в одном слове. Если не разместит, придется вам делать черти какой буфер команд и искать в нем подругу для склейки. Это если вы хотите сделать крутой процессор. Если простой, то два такта и отдыхайте. Можно конечно просто запускать 2 команды за такт. Так вроде даже проще чем клеить две команды в одну. Но 2 команды за такт это уже два конвейера, многопортовый регистровый файл и т.д.
Поторопился немного :) Но уже не исправить. fusion это про Ерему, а я про Фому. Но Фома тоже не подарок.

Post increment как раз эффективней пилить на 2 микрооперации. В этом случае на out-of-order superscalar инкремент не будет дожидаться окончания лоада. А лоад может зависнуть на много сотен тактов в случае cache miss. А вот индексация массива по регистру лучше делается одной микроопераций: лоад всё равно нельзя запустить до того, как будет вычислен адрес. А адресация (base + offset) уже есть, то есть в address generation unit есть сумматор. В железе не слишком сложно завести туда данные из регистра вместо immediate value из опкода. В RISC-V эту задачу должен решить fusion, но пока не видно железа, которое это умеет. На моей прошлой работе такое пытались сделать (не для RISC-V, для собственной архитектуры), но это не заводились на частотах выше 350 МГц

спасибо. Беру на заметку.До out-of-order я еще не дошел :)
Можно, пожалуйста, объяснить, как именно ISA RISC-V способствует уменьшению количества выполняемых микроопераций? Macro-ops fusion — это, конечно, умно, но он позволяет превратить lookup массива аж в 2 микрооперации, тогда как в тех же ARM/x86 они без какого-либо напряга могут быть сделаны одной, были бы соответствующие исполнительные устройства.
Именно из-за этого 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 нельзя закодировать такую инструкцию

Без сжатия.
LW a0, a0, a1; a0 < — [a0 + a1]
Или смещение должно быть не в регистре?

В RISC-V смещение должно быть закодировано числом в инструкции. Регистр нельзя. Разработчики считают, что железо должно уметь склеивать две инструкции в одну в конвейере. Но такого железа пока не видно.

Ощущение, что нас где-то обманывают…
Сия фича была предложена в архитектуру RISC-V только в 2016, и, на сколько я знаю, нигде ещё не была реализована и не понятна когда и где будет. Так что вся эта хвалебная ода, это сравнение некоторого теоретического процессора с неизвестными характеристиками с реальными и работающими.
Когда только появилась первая версия R32I, была шутка про отсутствие бита переноса. Посмотрел как сейчас будет сложение 2-х 64-бит чисел в наборе R32I.
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, не проводя какого-то анализа других архитектур.

Зачем сдирать с MIPS, если RISC-V проектировали авторы MIPS? Они же авторы самой идеи RISC архитектуры. Ищите David Patterson & John Hennessy.

Про отсутствие анализа других архитектур, мягко говоря вздор. Даже на русский есть переводы анализа архитектур: Паттерсон «Компьютерная архитектура. Количественный подход. Руководство».

Это, простите, не анализ а научно-популярная литература для широкого круга интересующихся. Написано, правда, хорошо, этого не отнять.
Нормальный анализ делается с применением потактовых симуляторов, и приводит к тому, что в архитектуре появляются инструкции, которые в RISC-V не представлены. В понимании авторов RISC-V, это должен обрабатывать instruction fusion. Но покажите мне железо, в котором это реализовано.

Это самый крутой из доступных без NDA учебник уровня старших курсов магистратуры вообще-то. Т.е. всё что круче — уже статьи в peer-reviewed журналах если повезёт, а если не повезёт (что скорее всего и будет) — патенты и внутренние публикации.


Монографий круче нет.

Спасибо, еще раз. По ссылке очень интересное замечание по поводу расстановки команд, чтобы процессор мог их выполнять параллельно если он может это делать. Получается, что если расставил «неудобно» для процессора, то он(процессор) тормознет :) Тогда в выигрыше те, у кого свой компилятор который удобнее расставит команды для «своего» процессора. По крайней мере процессор может быть проще.

В out-of-order superscalar это не настолько важно: в процессоре будет буфур декорированных инструкций, из которого процессор будет брать готовые для исполнения команды. И по большому счёту не очень важно, в каком порядке они идут в коде программы. Вот в in-order superscalar важнее, чтобы компилятор правильно расставил инструкции. Для этого в компиляторах планировщики пишут. В out-of-order компилятор тоже более-менее оптимально пытается расставить инструкции, но это нужно скорее для того, чтобы декодирование не тормозило.

У ARMv8 уже нет встроенных сдвигов

Есть. Но сильно ограничены: только LSL на размер данных в LDR/STR.

«Одно из условий RISC-V для разрешения слияния операций в одну — это совпадение целевого регистра. Это условие выполняется для команд ADD и LW (load word, «загрузить слово»). Поэтому процессор превратит их в одну команду.»
А почему не эти?
C.SLLI a1, 2; a1 ← a1 << 2
C.ADD a0, a1; a0 ← a0 + a1
По теории автора — не совпадает целевой регистр (a1 и a0). Придется в одном такте писать в регистры сразу два результата. Видимо, по их теории, так делать нельзя.
То есть запись от первой команды можно игнорировать, просто передав ее результат bypаss во вторую. Тогда понятно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий