> RISC-V -- открытая архитектура. Не нужна суперскалярность,
> нарисуй себе RISC-V без суперскалярности. Ну так в систему команд оно и не вхаркожено особо. И таки нарисовали и такие реализации тоже. А козыряя "типа фичой" стоит понимать что в половине случаев фича легко превращается в жирный баг. И крутизна ARM в том что они смогли все это избежать, ухитрившись сделать какую-никукую консистентность системы команд при нефиговой масштабируемости.
> Консенсус на HN, если почитать комментарии: RISC-V займёт нишку "встраиваемых" ядер.
К этому есть сильные предпосылки.
> В частности и тех, где предсказуемость в большем приоритете нежели производительность.
Он, в принципе, может - потому что нвидия выбора особо и не оставила. Никто не потерпит прямого конкурента как лицензиара ядер. Равно как нвидия не знает специфику области и экосистемы МК и уж куда как враждебнее к девам чем ARM сейчас.
Но мы же про заточенность ядра? И вот в RISCV как таковой не имеет никаких особых козырей для управляющих систем. Cortex-M были несколько адаптированы, чтобы делать это удобно. В RISCV это никто не делал. Ну вот не были его авторы вхожи в это и не в курсе как real-world применения выглядят.
Если ARM coretex M вызывает "вау, как клево, аккуратно, продумано и удобно" то RISCV - ну, обычное "искусство" рядового мясника. Там правда фирма ARM много интересных фокусов запатентовала, не отнять.
> В качестве CPU у нас будет ARM, а вот всякие "сопроцессоры", контроллеры
> и прочие будут под RISC-V.
С учетом покупки ARM nvidia это уже вообще не факт. Как вы представляете себе лицензирование крутых ARMов прямым конкурентам нвидии? Вот жизнь и не оставила им выбора кроме как развивать что-нибудь еще. А другого не так уж много, 64-битные версии RISCV с расширениями не так уж далеко от cortex-A. И вон та штука с pcie под видяху - про вон то самое уже.
А в микроконтроллере столько - не надо! Там от этого один вред. Пока там 32-битных ядер всем за глаза, от 64 только код пухлый, а памяти и близко не 2^32. Накристальный NOR дорого стоит, площадь кристалла сильно жрет. И тонкий техпроцесс для МК же баг а не фича, хлипкий чип получается. Что хреново для управляющих систем, потом 20 лет ГАРАНТИИ сохранности фирмвары в флеше, при +105 желаемых автомотивщиками - ну, ой. А, представляете, это паяют куда попало, в том числе и в то что жарится у вас под капотом. И как вы понимаете, 7 нм NAND при +105 утечет быстрее поросячьего визга, юзер получит встрявшее на дороге авто, спасибо если не впечатавшееся в соседа, и кому оно в таком виде будет надо?
> Я не уверен, что я согласен с этим, но с другой стороны не думаю, что правильно было
> бы заигнорить это мнение.
На этой планете довольно много тех кто не прочь забить гвоздь микроскопом. Но вообще логичнее наоборот: нвидия точно будет душиться жабой на апликушные тяжеловесы, т.к. сами не прочь в этом сегменте потусоваться, а микроконтроллерная мелочь по жизни не их бизнес и там нет особого конфликта интересов. Но они в область не вхожи и обречены наломать дров.
> В RISC-V это решается более грамотно. Собирая себе процессор, ты выбираешь какие
> части системы команд он будет поддерживать. Блоками.
Ну так ARM и сделал примерно так же, только логичнее и тематичнее, с осмысленной разблюдовкой под задачи а не сферически-абстрактной модульностью в вакууме. Которая к тому же создает проблемы с совместимостью.
> Вот теми блоками, как они в спецификациях описаны.
Ну да. Однако вот именно нормальной спецификации "для микроконтроллеров" там как таковой и нет. Поэтому в целом оно на задачу похуже Cortex M от арм ложится, особенно в low end где больше жесткого реалтайма и предсказуемости и меньше мегагерцев с гигабайтами, потому что там не в этом счастье. А в том чтобы на вон тот раздражитель за наносекунды что-то сделать - и без дикого джиттера (привет кэшам и проч). А кому там нужна дерганая непредсказуемая система, которая вот так в дедлайн укладывается, а вот так - лажает? Реальное время ждать не будет, и если это вопрос в том не #$%нет ли что-нибудь от этого - сие уже аргумент. По этому поводу пики и авр до сих пор живые. Они тупы как дрова, но вот *ГАРАНТИРОВАННОЕ* время реакции на событие считается с точностью швейцарских часов, потактово, и даже жалкие 10 МГц просчитанные потактово - оперирование квантами времени по 100 наносекунд. А когда у тебя толи 10 наносекунд, толи 200, смотря hit оно там или miss, так уже не катит. И вот тут мелкий уродец пик воткнет жирному апликушному процу как делать нефиг. По поводу чего и выпускается до сих пор, хоть и не стоит добрых слов по архитектуре.
> Да. Я почти о том же. Единственное отличие, я не склонен их
> винить в этом: они разрабатывали ARM ещё до того, как суперскалярность
> и out-of-order execution вошли в моду.
Это про RISCV было. Фирма ARM доперла сделать "профайлы" под "задачи", логично сгруппированые, и даже частично отбросив легаси. Это было эпиквином, абстрактные блоки - несколько менее об этом. Какую-то адаптивность под задачу получить можно но в целом кривее и неудобнее. Так что ARM - state of art, RISCV - такой art как мясник с топором супротив шефповара. Но если вопрос в том что шефповар шашлык сам сожрет, народ и на мясника согласен.
> Ну а мне как-то совершенно фиолетово.
Я могу с этим жить, но симпатий к процессорному ядру это не добавляет. После ARM это ощущается как даунгрейд и легаси. А почему, собственно, хоть к 2020 нельзя бы сделать проц удобный системщикам? Особенно когда ARM все это смогли?
> До тысячи строк ассемблерного кода -- это такая штука, которую легко можно поддерживать.
Да как сказать? Если ты не писал этот код, удовольствие одуплять в 1000 строк этого счастья довольно так себе. Си все же может быть сильно декларативнее на тему того что и нафига тут происходит. И какой-нибудь pll_reclock(100, 200) будет информативнее того как это на асме будет. Особенно ежели рантайм параметры захотеть. При том что си можно убедить стать очень тонким shim над железкой, когда код будет тот же как я сам бы сделал, или лучше (глобальные оптимизации в 1К команд я вероятно прошляплю).
> Можно хоть переписать с нуля, если что. Даже если система команд не нравится. На такой
> кодобазе бонусы всяких там C мало сказываются. Если вообще сказываются.
Можно. Но в целом это оказывается такой кусок кода который никто предпочитает не трогать. Потому что кус черной магии, в которую надо непропорционально долго вкуривать. И допереть по этой кучке россыпи что это pll_reclock(100, 200) довольно неудобно. Хоть и делается.
