Comments 43
А разве "модули" не платные? Насколько я понимаю в арме платят за использование ядра, а у Risc-V, так сказать, "база" предоставляется бесплатно, но различные расширения надо уже приобретать
Никогда не слышал про оплату расширений.
Почему же такая популярность? Созрела потребность в открытой и свободной компьютерной архитектуре.
Открыта и свободна. .
Каждый может стать членом этой организации, каждый может внести пассивный вклад в развитие архитектуры.
вот про пассивный вклад хотелось бы поподробнее.
рост производительности микропроцессоров более-менее закончился
я бы сказал "замедлился"
RV32I означает архитектуру RISC-V,
32-разрядную, I означает наличие целочисленной арифметики. Эти параметры
— джентльменский набор для того, чтобы поднять операционную систему.
Это базисная архитектура, которая позволяет запускать операционную
систему на микропроцессоре.
Здесь серьезная неточность. RV32I это минимальный минимум, всего 38 инструкций! Этого набора недостаточно для того, что бы запускать операционную систему общего назначения с виртуальной памятью (ОС Linux). Для такой ОС требуется поддержка расширений из набора RV32GC. Буква C - это обязательная поддержка системы сжатия иструкций (compressed commands). Буква G - это совокупность букв MAFD, которая расшифровывается так: M - "умножение и деление", A - "атомарные инструкции", F - "операции с плавающей точкой" и D - "операции с плавающей точкой двойной точности". При этом, когда мы говорим о RV32GC (RV64GC или RV128GC) подразумевается, что система-на-кристалле снабжена блоком управления памятью (MMU) который обеспечивает виртуализацию адресного пространства. Блок MMU не имеет своих инструкций по этому не является одним из стандартных расширений RISC-V, но его наличие является обязательным для современных операционных систем.
PS: Для желающих пощупать Linux на живом микроспроцессоре RISC-V есть одноплатный ПК Sipeed Lichee RV на базе СнК Allwinner D1 который содержит ядро RV64GCV (V - векторые вычисления).
Здесь серьезная неточность. RV32I это минимальный минимум, всего 38 инструкций! Этого набора недостаточно для того, что бы запускать операционную систему общего назначения с виртуальной памятью (ОС Linux).В процитированном вами сообщении ни слова про Линукс или про другие «ОС общего назначения с виртуальной памятью». Маленькие RTOS для эмбеддед — тоже ОС )
И даже MS-DOS тоже операционная система, только родом из 80-х. Тем не менее в современном мире под ОС понимается как минимум Linux (а чаще - Windows). Таким образом утверждение "Это базисная архитектура, которая позволяет запускать операционную систему на микропроцессоре" вводит неискушенного читателя в заблуждение.
Тем не менее в современном мире под ОС понимается как минимум Linux (а чаще — Windows).Нет.
Ну просто нет.
В современном мире гораздо больше копий ОС в разной встраиваемой технике, чем копий windows. И целевая аудитория этой статьи — не обыватели с ютубчика, а люди с айтишным бэкграундом, понимающие, что такое ОС для встраиваемой техники. Иначе зачем им вообще понимать, в чем преимущества RISC-V перед другими ISA?
Уровень статьи - для студента с ардуиной. В целом про RISC-V не написано ничего, кроме того, что это бесплатно и за этим будущее. По этому не надо убеждать меня в том, что автор имел в виду различные специализированные ОС и нацеливался на разработчиков микроархитектур.
PS: В "различной встраиваемой технике" сейчас копий Linux-а существенно больше чем всех остальных ОС вместе взятых.
Затем, что программировать под Linux гораздо проще чем под FreeRTOS во всех аспектах. Потому, что современное поколение программистов ничего кроме Python-а не знает. Я не поддерживаю такую всеобщую линуксовизацию, но ни Вы ни я повлиять на эти тенденции не можем.
Монстр с линуксом сейчас стоит столько же сколько и 4-битный микроконтроллер. Так, что все экономические прелести от удешевления аппаратуры давно нивелированы высокой стоимостью разработки ПО. Более того, сопровождать ПО написаное под Linux существенно дешевле чем натянутое каким-то одним гением FFT на сову, и найти таких людей проще. Гения нет и начинай разработку сначала. Я в своей практике постоянно сталкиваюсь с заказчиками, кторые приходят и говорят "вот нам тут кто-то что-то когда-то разработал для PIC, нельзя ли доработать и добавить пару простеньких но очень нужных фич ?". Ответ всегда один - "можно, но стоимость таких работ превысит стоимость разработки нового изделия на более современной базе с Linux-ом".
А кушает монстр с линуксом столько же, сколько и 4-битный микроконтроллер? И обвязки никакой дополнительной не требует? И несколько лет без перезагрузки проработает?
Всему своё место. На чипах под линуксом периодически приходится с ОС бороться за риал-тайм исполнение чего-нибудь, часто именно по причине того, что зачем-то заложили линукс. Но богатая периферия и дополнительные ядра в таких чипах спасают, да.
Дак вопрос надежности уже давно никого не беспокоит - чем чаще железяка ломается, тем лучше - это же понятно даже школьнику. ;) Риал-тайм ? Накиньте больше ядер и все дела. :-)
С ядром Linux-а действительно очень много борьбы. Но так как этой борьбой занят почти весь окружающий мир, то вопросы решаются достаточно быстро. Проблемы начинаются тогда, когда заказчик хочет пересесть с одного дешманского китайского СнК на другой (например с Allwinner T2 на T3). Вот тут свистопляски с драйверами выползают по полной, так как T2 поддерживается последним ядром почти на 100%, а T3 - едва ли на 10%.
А он, тем временем, с распространением IoT становится все актуальнее и актуальнее.
Это была шутка юмора, или попросту сарказм.
Я прекрасно понимаю все проблемы связанные с "большими чипами", но тенденции таковы, что труд программистов умеющих "натянуть сову на глобус" обходится существенно дороже, и найти таких очень и очень не просто. По этому в подавляющем большинстве имеем Linux и Python там, где без этого можно обойтись.
Стоимость программирования (программиста) делится на число созданных устройств. А вот стоимость устройств суммируется для всего проекта.
Иначе говоря, если программист стоит миллион, но выпущено миллион изделий, то для каждого изделия это всего лишь +1.
А вот если устройство стоит на +10 дороже, что бы его мог модифицировать задешиво любой мамкин программист, то это ни с какой стороны не выгода.
Для штучных, разовых, мелкосерийных конечно подход другой. Часто вижу как вообще, не разрабатывают свое устройство, а адаптируют отладочные платы.
Именно так, но есть нюансы:
Cпециализированные устройства редко имеют большую серийность, тем более в России. Выйти на массовый потребительский рынок - удел избранных.
Любое устройство имеет свой жизненный цикл, на протяжении которого это устройство требуется сопровождать. Т.е. работа программиста не заканчивается после того, как изделия пошло в серию, и производитель продолжает нести затраты на программистов.
А кроме Risc-V, ни чего не рассматривается?
Мне эти утверждения, что RISC лучше CISC непонятны. Да меньше инструкций и быстрее типа CISC, но для того чтобы сделать на малом наборе инструкций что-то надо писать больше кода. Получается меньше аппаратной части, больше программной и где выгода? В скорости точно выгоды не будет. Ну да ARM взлетел и Apple даже ноут выпустила на M1, но для каждой области своя архитектура важна.
По факту компиляторы оптимизируют далеко от идеала, даже на более примитивных платформах типа STM32, поэтому разница получается не очень заметной.
но для того чтобы сделать на малом наборе инструкций что-то надо писать больше кода.
Чуть больше кода (до 10% что ли) придется рожать компилятору и ассемблерным прогерам, для остальных не изменится ничего. С учётом ограниченного количества регистров общего назначения в типичных x86 и, как следствие, перекидывания операндов из регистров в память, кода там вообще может получиться одинаково.
Получается меньше аппаратной части, больше программной и где выгода? В скорости точно выгоды не будет.
Будет. Скорость определяется несколькими факторами.
Скорость в случае конвейеризации и out-of-order выполнения достигается за счёт извлечения максимального количества параллелизма из инструкций и высокой тактовой частоты. В случае CISC эти инструкции большие и очень разнородные, параллелизм извлекать сложно, нужно учитывать большое количество их правил. В случае RISC инструкции предельно простые и однородные.
Понимая это и стремясь извлечь больше параллелизма из CISC, начиная где-то с 90-х проектировщики CISC-процессоров под капотом раскладывают инструкции на маленькие RISC-подобные микрооперации, при этом имея много гемора с декодингом разнокалиберных CISC-инструкций, выборкой на границе строк кэша, режимами адресации с памятью, спекулятивным выполнением этого всего и откатом в случае ошибок предсказаний (многочисленные примеры проблем есть в этой книжке). Логика для этого не только занимает место на кристалле, но и ухудшает тайминги -- тактовую частоту, и как следствие бьёт по скорости.
Выбрасывание большого количества логики в случае RISC позволяет помещать ешё и более крупные кэши на кристалл, что тоже даёт буст к скорости, за счёт уменьшения числа промахов кэша.
Выгод несколько:
1) Меньшая площадь кристалла, меньшее потребление, дешевле производство. Избыточную площадь можно задействовать под дополнительный кэш или под большие регистровые файлы (хотя от этой идеи отказались из-за проблем с переключением контекста в многозадачных ОС).
2) Более узкие ступени конвейера позволяют достигать тактовых частоты существенно выше чем у CISC (5ГГц и выше).
3) Простота исполнения. Как следствие - меньше трудозатрат, меньше штат разработчиков, цикл разработки существенно короче, продукт быстрее выводится на рынок.
Тезис о том, что для RISC нужно больше инструкций чем для CISC что бы выполнить одну и туже работу давно не соответствует действительности - RV64GC решает эту задучу успешно за счет instruction compression и macro-op fusion. Объем бинарного кода стандартной библиотеки Linux-а для RV64GC на 30% меньше чем для AArch64, в пересчете на мегагерц она исполняется быстрее и имеет меньший отпечаток в оперативной памяти.
Вообще, что бы понять в чем суть идеи RISC нужно плотно ознакомиться с работами Дэвида Паттерсона и Джона Хэннесcи. Возможно, что автор этой статьи в следующих частях посветит нас хотя бы кратенько в суть этих работ, расскажет нам как создавалась система команд RISC-V, в чем её особенность и отличие от других, так же называющих себя RISC, систем. Почему в базовой версии всего 38 инструкций, а не 58 и не 25. Как организованы инструкции и почему в RISC-V ISA нет инструкции MOV.
И еще. Современные ARM ядра очень далеки от RISC. Система команд ARM это помойная яма, такая же как и x86.
Современные ARM ядра очень далеки от RISC. Система команд ARM это помойная яма, такая же как и x86.
Если в RISC-V реализовать все расширения , то это будет такая же "помойная яма" как и ARM. Если сравнивать 38-инструкций RISC-V , то нужно брать у ARM версию v4. Отличная система команд и на ней когда-то работал Pocket PC.
От части Вы правы. Но нужно понимать, что все расширения набора команд RISC-V они очень минималистичны, добавляют только то, что нужно без избытка. Более того, все инструкции очень тщательно вымеряны и статистически обоснованы. К примеру, мне очень сильно нравится как сделано векторное раширение (RVV) - идея позаимствована у Сеймура Крэя и его машин из 80-х, но доведена до совершенства.
С моей точки зрения, среднестатистический процессор общего назначения архитектуры RISC-V должен соответствовать RV64GCV, это около 70 инструкций. Для сравнения, ARMv8 (A64) содержит целых три набора системы команд в сумме более тысячи инструкций. В ARMv9 накинули еще пару десятков. Так же в ARM есть множество недокументированных (hidden) инструкций, что, по мимо всего прочего, представляет брешь в безопасности.
И еще момент. В RISC-V нет флагов. Флаги это большая заноза для разработчиков суперскалярных OoO микроархитектур так как тянет неявные зависимости между инструкциями, что делает планировщик (декодер) очень сложным. Разрабочики RISC-V ISA решили избавить проектировщиков будущих микропроцессоров от этой проблемы, что, теоритчиески, позволит увеличить производительность при меньших аппаратных ресурсах.
С моей точки зрения, среднестатистический процессор общего назначения архитектуры RISC-V должен соответствовать RV64GCV, это около 70 инструкций.
G это IMAFD. Простой пересчет строчек в таблице дает 159 команд. Расширение С - 49 строк в таблице. Хотя , С-команды это просто конвертор в обычную команду и её можно даже не считать за код. Количество векторных команд подсчитать сложно, т.к. куча всевозможных вариаций и непонятно как их считать и сравнивать с ARM.
все расширения набора команд RISC-V они очень минималистичны
Если , для примера, взять расширение В, то даже в нем можно увидеть несколько подрасширений :) Обязательная часть и необязательная. Я не представляю как в таких условиях писать софт.
Если взять расширение Р, то на нем можно запросто сгородить полноценный DSP-процессор. Получается , что нет никакого минимализма, а есть попытка покрыть своим знанием все что есть на текущий момент в микропроцессоростроении. И это конечно же не конец. Как только у конкурентов появляется что-то интересное, мы тут же увидим новое расширение RISC-V :)
Я считал по опкодам и у меня получилось 71 инструкция. Каждая инструкция имеет параметр function которая задает режим её работы. Если рассматривать комбинации opcode + function, то получится около 300 вариантов.
Если , для примера, взять расширение В, то даже в нем можно увидеть
несколько подрасширений :) Обязательная часть и необязательная. Я не
представляю как в таких условиях писать софт.
Так как архитектура находится в движении, то писать софт нужно ориентируясь на конкретное железо. Полагаю, что со временем все устаканится, будут приняты/рекомендованы "суповые" наборы расширений типа RV64GC.
Получается , что нет никакого минимализма, а есть попытка покрыть своим
знанием все что есть на текущий момент в микропроцессоростроении.
Люди пытаются систематизировать накопленные за 50 лет знания и опыт в микропроцессоростроении - откинуть все лишнее, остальное огранизовать так, что бы была система, с прицелом на упрощение аппаратной реализации. И сделать это доступным для всех.
И это конечно же не конец. Как только у конкурентов появляется что-то интересное, мы тут же увидим новое расширение RISC-V :)
Я наблюдаю обратную тенденцию: ARM начал вычищать свою ISA и делать её более похожей обратно на RISC. А последнее расширение SVE2 так вообще полностью скопировано с RVV. К чему бы это ?
откинуть все лишнее, остальное огранизовать так, что бы была система, с прицелом на упрощение аппаратной реализации
Я с вами полностью согласен. Плюс еще чтобы и с компиляторами было проще. Но я не согласен только с одним - отбрасывая "что-то лишнее" не стоит говорить, о чем-то гениальном. Наблюдается обычный эволюционный процесс.
Тезис о том, что для RISC нужно больше инструкций чем для CISC что бы выполнить одну и туже работу давно не соответствует действительности - RV64GC решает эту задучу успешно за счет instruction compression и macro-op fusion.
В вопросе размера кода macro-op fusion вообще не при делах. Это совсем другое. Расширение "С" это конечно хорошая штука, но лично я думаю, что в данном случае решающее значение в размере кода за хорошей командой компиляторщиков и довольно удобной для компилятора архитектурой (около 30 рон).
В вопросе размера кода macro-op fusion вообще не при делах.
Очень даже при делах. Вот небольшая презентация от Отцов Основателей на эту тему, в конце очень много интересной статистики: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fusion-finalV2.pdf
И Вы совершенно правы, RISC-V ISA разрабатывалась для компиляторов без ненужного и давно забытого багажа, как у ARM и x86.
Спасибо за ссылку на презентацию. Ваша ссылка на macro-op fusion ввела меня в заблуждение. Там вроде в основном о технике, как несколько инструкций кода сжать внутри процессора в одну операцию. Соответственно это не имеет отношения к размеру кода. Но есть еще и другой fusion , который как раз подходит. Это объединение пары типовых команд в одну. Как пример, сравнение а затем переход, у RISC-V это одна команда. Подобный fusion действительно сокращает размер кода.
К сожалению, для того чтобы нормально ответить на это вопрос, нужно рассмотреть не только архитектуру (систему команд), но и микроархитектуру (структуру конвейера процессора). Если одной фразой - RISC процессор проще конвейеризировать чем CISC, откуда следует его более высокая энергоэффективность (за счёт уменьшения размера и уменьшения количества переключающейся каждый такт логики), а также следует существенно меньшее количество инженерных ресурсов (человеко-лет) на его проектирование и верификацию.
...... Пропускаю несколько страниц объяснений ....
Таким образом, для реализации CISC необходимо не только изменить front-end процессора (стадии выборки и декодирования инструкций), но и протащить связь исходных инструкций с декодированными микроинструкциями до самого конца конвейера для корректной отмены инструкций в случае возникновения прерывания. CISC также усложняет предсказатель перехода и другие части процессора. CISC сложнее в верификации (= требует бОльших инженерных ресурсов).
Конкретно у x86 при этом ещё и недостаток количества регистров. Двухоперандные команды требуют более сложных байпасов и переименования регистров (алгоритм Томасуло или эквивалент).
Помимо описанных недостатков для процессоров десктопного класса, существует ещё более серьезные недостатки для встроенных процессоров и ядер для микроконтроллеров.
Малое RISC ядро может спроектировать даже один проектировщик и хорошо верифицировать небольшая группа людей. Для x86 это не так даже малое ядро будет сложным и как минимум, проигрывать в энергоэффективности.
Если пытаться объяснить с минимумом слов: в RISC (по сравнению с CISC) проще организовать как выполнение инструкций с перекрытием выполнения по времени (пока одна инструкция декодируется, другая выполняется) - конвейерность, так и выполнение инструкций параллельно с учётом зависимостей между ними - суперскаляр.
Это "проще" значит как "с меньшим количеством транзисторов" так и "с меньшим количеством инженеров".
БОльший параллелизм у RISC как в смысле конвейерности, так и в смысле суперскаляра (если сравнивать процессоры с одинаковым количеством транзисторов и одинаковой тактовой частотой) компенсирует его меньшую плотность кода, чем у CISC (где нужно меньше инструкций, чтобы выполнить то или иное действие). Это доказано некоей статьей 1990-го года (могу нарыть - до нее 10 лет спорили на тему) и последующими исследованиями)
Побочным эффектом от этого является бОльшая энергоэффективность RISC (производительность / милливатт).
А есть cisc с осовремененным набором команд?
Это показательный пример того, как важно поддерживать наборы компьютерных команд как можно более простыми.
Вообще это ни из чего не следует. Так вы до OISC докатитесь.
Во всём нужен баланс. ARMv9 это большой и прагматично созданный набор команд.
Некоторые команды ARM могут заменять несколько команд x86 или RISC-V.
Некоторые команды ARM могут заменять несколько команд x86 или RISC-V.
Интересно какие.
Вы всегда про armv8-9 говорите, какой он прагматичный и эффективный. Интересно увидеть пример
Так может к oisc однажды и придёт всё
Есть такая дилемма - чем высокопроизводительней архитектура, тем сложнее у неё система команд. Как бы не тяготел инженерный разум к фундаментальности и простоте, здесь начинает действовать лингвистический принцип усложнения языка с усложнением деятельности его носителя. Вероятно, можно обойтись и 30 словами, но эффективно выражать ими сложные мысли очень тяжело. Маленькая ISA просто пережимает канал между алгоритмом и исполнителем, и вытаскивать производительность из доп. информации, которую может знать компилятор, там не получится - через RISC ISA её не передать. Поэтому мы и видим то, что видим - в PC и серверных архитектурах ISA расцветает сотнями инструкций.
Есть такая дилемма - чем высокопроизводительней архитектура, тем сложнее у неё система команд.
Пришло время ложных дилемм?
В качестве контрпримера приведу супервысокопроизводительную для своего времени архитектуру с простой системой команд -- DEC Alpha.
Чем сложнее система команд, тем больше железа требуется на реализацию этого всего, тем сложнее это всё заставить работать с приличной скоростью и тем больше оно ест энергии.
Поэтому мы и видим то, что видим - в PC и серверных архитектурах ISA расцветает сотнями инструкций.
Мы видим это из-за огромной кодовой базы, которую нельзя просто взять и выкинуть по мановению волшебной палочки, а также из-за кучи сложившихся исторически вещей.
Тот случай, когда комментарии читать интересней, чем саму статью :)
Почему RISC-V? — лекция Станислава Полонского