>> ... где-то на просторах интернета должны быть подробные разборы тому, почему это так.
> Например, вот: https://habr.com/ru/post/461785/ Та ссылка, которую ты предложил, это не "_ОЧЕНЬ_ раскритикована", это аргумент вида "у ISA есть недостатки". Но любое инженерное решение -- это компромисс, и любой компромисс можно изложить в виде "у него есть недостатки". Если тебе это непонятно, я могу навскидку накидать тебе два десятка пунктов описания недостатков x86, linux, Rust, C, Python, и практически чего угодно, с чем я хорошо знаком. И чем лучше я люблю и знаю технологию, тем больше надостатков я накидаю.
Мнения экспертов-теоретиков мало интересны и мало информативны. Я так могу quicksort взять, и начать рассказывать о том, что поскольку при разработке алгоритма было принято решение проводить её in-place, то это приводит к ряду недостатков и, в конечном итоге, не позволяет достичь максимальной скорости сортировки. Могу ещё сравнить с баблсортом, и показать, что поскольку большинство сортирующихся массивов небольшого размера, на которых баблсорт показывает себя лучше квиксорта, решение писать вместо трёх строк прямолинейного баблсорта, несколько десятков строк запутанного квиксорта -- весьма сомнительная идея.
Или, скажем, лет пять назад поцреоты нашей космонавтики усиленно репостили ссылку на какой-то разбор от нашего космического теоретика, который рассказывал что повторное использование ступеней ракеты приводит к необоснованному усложнению этих ступеней, потому что их сложно возвращать на землю без того, что Маск называет RUD (rapid unscheduled disassembly), и результатом будет удорожание запуска, а не удешевление. Такова была теория, но сегодня про неё почему-то никто не помнит.
Или, опять же, лет пять назад, когда РФ начала строить мост в Крым, был какой-то теоретик -- кандидат наук между прочим -- который рассказывал о структуре дна в Керченском проливе и о том, что мост не удастся построить из-за этой структуры.
Теоретические споры об инженерных решениях -- это хорошо в процессе разработки этого решения, но если дело дошло до реализации решения, то... как там было: theory and practice sometimes clash. And when that happens theory loses. Every single time. (c) Torvalds. Я очень люблю эту его цитату, она показывает где и как умирают теории и идеологии. И на мой взгляд, она отличает инженера от теоретика.
То есть, спасибо за ссылку, интересно почитать, но это теоретические недостатки. Реальные недостатки RISC-V нам ещё предстоит выяснить. Реальные недостатки -- это те, которые проявляют себя на реальных задачах. Но такие недостатки ты сможешь найти в статьях вида "я тут взял RISC-V и запилил на нём девайс X, обычно я девайсы типа X делаю на ARM, но тут сделал на RISC-V, вот фоточка моего ARM девайса, вот фоточка нового RISC-V девайса, а дальше у меня тут tl;dr на 20 килослов сравнивающий опыт разработки на ARM с опытом разработки на RISC-V". Сейчас есть реальные RISC-V, есть куча схем разных реализаций RISC-V на github'е, можно гонять в симуляторе или на FPGA. Ждём драматичных рассказов о том, как инженер убил в адаптацию RISC-V под свои задачи полгода, и из этого вышло "так себе", хуже чем на ARM'е. Или лучше.
> Ну, и на форуме realworldtech.com тоже были обсуждения. Теми, кто хорошо разбирается
> в системах команд, RISC-V ISA там была _ОЧЕНЬ_ раскритикована.
Ну, знаешь, я не пойду искать. Интернет споры хороши тем, что оппонент кидает в тебя аргументами и ссылками, которые позволяют узнавать новое. Когда же вместо ссылок он неспецифично отправляет в гугл... зачем мне нужен такой бесполезный оппонент? Неспецифично сходить в гугл я могу и сам.
