> Как уже много раз писал, RISC-V прекрасен для своего первоначального предназначения (простых
> встраиваемых применений типа стиралок и кофеварок, но не путать с IoT).Он прекрасен тем что
1) Это экосистема. Открытая. Чипмейкерская.
2) Уже есть легион ядер, самых разных масштабов. От low power MCU до серверных чипов. Открытых.
3) Есть нехило обвеса и SoC на это все. В чем можно убедиться зайдя на гитхаб.
4) Есть легион тулзов, самых разных. Вплоть до симуляторов которые могут анализировать с точностью вплоть до вентилей. Не говоря уж про компиляторы, системный обвес и все такое. И все это открытое, конечно.
5) Ах да, эта экосистема вертикально масштабируема. Как ARM. Одно ядро на одну оказию хорошо. Универсальная масштабируемая экосистема лучше.
6) Это эволюционирует. Шустро, динамично, под насущные задачи, толпой народа. В эту экосистему вписались легионы. От самоделкиных до корпораций размером с WD и чуть ли не интел.
> А дальше начинает фигня, напомню: Как у "чистого риска" нет явного указателя стека
А что же у него есть по вашему?
> и какой-либо защиты стека.
1) Реализуемо допустим MMU.
2) Если этого всего мало, вон там Rust на горизонте появился, он с другого бока зашел.
И между нами, компил тайм верификация лучше рантайм факапов. Особенно для безопасного, надежного и беспроблемного софта.
> При этом ABI вроде-бы входит в спеку архитектуры и предусматривает распределение регистров.
И это хорошо. Ибо дает определенные
> Поэтому де-факто имеет один стек, где данные смешаны с адресами возврата,
Не обязано вести к каким-то фундаментальным проблемам само по себе. То что в случае конкретно си это может отливаться в те или иные грабли, это вообще-то трабла именно сей, в дизайне ЯП.
> плюс "опенсорсные тулчены" которые иначе не умеют, плюс весь системный софт где
> это захардкожено.
Да и хрен с ним. Говоря за себя если выбирать между допустим разучиванием раста и проприетарного сишного тулчейна - ну, вы поняли. Rust и его либы мой дистро культурно втянет, технично обув MS/amazon/google на контроль, я уже вижу как они это делают. А проприетарный тулчейн это проприетарный тулчейн. Факап в самом core экосистемы.
Видите ли, системщики не настолько раки чтобы спрашивать ослиное позволение wannabe-божков с тулчейном. Это даже майкрософту популярно объяснили уже, на память о чем у них "драйверов нет" вон там под ARM/RISCV/... и полный пролет в экосистеме. Удачи :)
> В результате "новая перспективная архитектура" принципиально уязвима для
> ROP как относительно дремучие x86, ARM и т.п.
Ну, значит, Rust будут применять более активно и так тому и быть. Есть более 1 способа решить ту или иную инженерную проблему. В том числе и эту.
> сохранено всё необходимое для эксплуатации ошибок "выход за пределы буфера на
> стеке" и ROP.
Этот класс ошибок можно просто загасить с другого бока. На уровне тулчейнов и ЯП.
> то она "одностековая", причем соглашение об использовании регистров прописано в спецификации
> ISA.
Ну, как бы как одно прописали, так и другое можно прописать. Или вообще зайти к проблеме с другого бока, затребовав аннотации в сорце и чеканув их соблюдение при сборке. А переваливать все родовые травмы си на то что это косяки архитектуры все же криво.
> - либо отказаться от готовой инфраструктуры и самим "пилить" все задачи связанные
> с изменением ABI (от доработки компиляторов до перепортирования софта);
ИЧСХ в случае с RISCV и его тулчейнами это даже какие-нибудь мелкие исследователи могут попробовать. А если получится что-то годное, почему бы остальным на это не свалить, не понятно. Ну вон у арма был EABI а потом стал ARMHF. И ничего, живые все.
> - либо всеми силами не замечать проблему, и убеждать себя и всех
> и что её нет.
А в каком-нибудь Rust и т.п. яп ее может и не быть в именно вон той формулировке. А в си, видите ли, реальная проблема в том что в сорце нет достаточной аннотации намерений кодера в ряде случаев, что нагибает статический анализ. Это я как сишник повернутый на надежности, стабильности и безопасности говорю. Ну вот реально есть дурные моменты дизайна. И это наследие си, а не чего-то еще. Особенно то что там касается UB где комитет свалил все и вся на кодеров и тулчейны, и указатели где ну вот вообще никакой декларации намерений кодера тулчейну а потому сие не предмет для какой либо верификации во время компила. Это само по себе грабли, гораздо более крупные чем одно только переполнение буферов.
> 1) разделение стеков существенно уменьшает вероятность/риски эксплуатации ошибок
> переполнения буферов размещенных на стеке.
Нормальная аннотация намерений кодера и статический анализ не то что уменьшает риски, они вообще целые классы багов на нет сводят.
> 3) в RISC-V ISA для инструкций JAL и JALR явно специфицированы автоматическое
> выполнение push/pop в RAS (return-address stack), т.е. «уши» аппаратного стека
> всё-таки торчат, но и нет проблем отделить RAS от SP с данными.
Обычное поведение обычного проца и упрощает некоторые системные вещи типа handler'ов если хочется их делать все же не на ассемблере, бжад. А кому сейчас хочется с ассемблером возякаться, даже там?!
> предлагают заменять "неперспективные Эльбрусы" на "прогрессивные RISC-V".
Я не думаю что это корректная постановка вопроса. Этих эльбрусов существует полторы штуки, с кучей дурных проблем, экосистемы толком нет, полтора инвалида с проприетарным тулчейном и внемайнлайновым викидышем это не вообще экосистема. А заодно вон та чудная фирма за 20, чтоли, лет не смогла то что вон те мелкие стартапы осилили за 4-5 лет.
Все же в проце главное не какой там стек, и регистры, а вменяемость общего сочетания парметров. С чем у эльбрусов жесточайше не задалось. Все думали что итаник это фэйл и ниже падать некуда, но оказалось что это не предел.
