МЦСТ раскрыл исходные коды компонентов Linux, системных библиотек и ПО для платформы «Эльбрус»

Директор по развитию МЦСТ (разработчика процессоров «Эльбрус») Константин Трушкин представил на совещании мини-ПК, который компания, по его утверждению, готова «переупаковать» в консоль.

Собственно, о чём ранее и шла речь.

Там risk-v добавлен в качестве контроллера который с датчиков температуры данные собирает и обрабатывает, раньше как я понял это все обрабатывалось в ALC0 в основном потоке. Через него же кстати и инициализация железа с загрузкой происходила (там было специальное устройство со своими регистрами).
А теперь если я правильно понимаю у них будет свой Эльбрус Мanagment Engine на Risk-v32e

Причём 32-бит ARM более интересный, потому что имеет включение инструкций по флагам (в e2k есть подобное с предикатами), в 64-бит ARM (AArch64) лишь несколько инструкций таких оставили

Так они и стырили это с vliw, подумав что это классная идея, вот только предикат в случае risc бесполезен так как занимает целую инструкцию, в итоге в aarch64 сделали как у интела просто условные комманды типа cmрj cmov.

LLVM впринципе против альтернативных бакендов, даже опенсорсных.
К этой какашке лучше вообще не прикасаться, gcc наше все.

Всё правильно. Никакого разброда и шатания быть не должно, все улучшение должны заноситься в проект и быть хорошо интегрированными.

Да, нотолько это уже не свободный код, а вендорлок по сути. Если ты думаешь что только у эльбруса с LLVM проблемы то ты сильно заблуждаешься, они у всех у кого архитектура не похожа на x86/arm/powerpc. В том числе речь про dsp и gpu.

Очень даже свободный. Не нравится политика проекта - форкай, развивай на здоровье. Вон, МЦСТ не в состоянии со своей проприетарной лицензией туда влезть - форкнули, допилили что надо. То же самое касается и остальных. Открывайте код, доводите до нужного уровня - его примут.

Это уже тянет на написание своего компилятора, что мцст и сдели. А что бы без скандалов, интриг и гемороя получить фронтенды llvm, они написали библиотеку кторая просто LLVM-IR конвертирует в EIR.
В итоге вся вот эта схема естественно выплевывает дерьмокод, а добавлять ключик что бы llvm выплевывал удобный аst для компиляции другим бакендом никто не будет принципиально, подпирай наше говно гигакостылями (как амд пыталось для gpgpu) но об альтернативном бакенде даже не думай, а то мы без монопполии останемся.

Еще раз: нет никакой монополии, когда есть альтернативные компиляторы. У людей есть видение и архитектура, которой они придерживаются. Если проприетарщина МЦСТ не вписывается в этое видение, это проблемы МЦСТ. Которые, кстати, решаются весьма просто: открытием компилятора и отправкой патчей для полноценной реализации в LLVM. Костыли для локальных проблем проприетарщины не нужны.

проприетарщина МЦСТ не вписывается в этое видение, это проблемы МЦСТ.

А когда проприетарщина от [квалкома](https://youtu.be/nfyuFPc5Iow?t=961) шлет патчи для улучшения планирования инструкций/раскрутки циклов специфичных для своего vliw процессора это улучшение компилятора и совсем другое, да?

У людей есть видение и архитектура, которой они придерживаются.

Ну так им и предлагают позволить вливам иметь свой бакенд и разрешить использовать фронтенды для llvm.
«Отвязывать фронтенды не дадим» и «крутитесь как хотите» это не свободное ПО, а вендорлок потому что фронтенды пишут не они, а те кто под их говно разрабатывал фронтенд долгие годы (тот же раст) получается теперь узник проекта llvm.

шлет патчи для улучшения планирования инструкций/раскрутки циклов специфичных для своего vliw процессора это улучшение компилятора и совсем другое, да?

Патчи открытые? Открытые. Архитектуру нарушают? Нет. Не вижу проблемы. Если МЦСТ пришлет кишки своего компилятора, их точно так же примут.

Ну так им и предлагают позволить вливам иметь свой бакенд и разрешить использовать фронтенды для llvm.

Чтобы что? Чтобы упростить жизнь разработчикам обскурной архитектуры, не существующей нигде, кроме РФ? Не нужно. Эта проблема должна решаться организационно, причем внутри самой МЦСТ, путем вышвыривания тупорылых сапогов и полного открытия исходников. Тогда и внешние бекенды прикручивать не придется.

это не свободное ПО

Свободное ПО - это лицензия. Не нравится политика апстрима - форкай, тебе никто не запрещает, доноси до мира, что разрабы LLVM плохие, потому что не хотят решать чужие организацонные проблемы путем добавления софтовых костылей, которые потребуют от них в том числе поддержки и осуществления гарантий совместимости, и кучу лишней работы в обмен ни на что.

Не примут, у них совсем другой компилятор с совсем другой архитектурой.

Что касается хексагонера то он предложил в архитектурно-независимую часть llvm добавить таргет-специфик код типа:
```
#ifdef HEXAGON
// ...разворачиваю циклы как хочу
#endif
```
Приняли или нет не знаю, скорее всего нет ибо для железа свой загон. Проблема в том что llvm все оптимизации связанные с кодом программы делает до того как код попадет в архитектурно зависимый бакенд, то есть туда попадает уже трижды пережеваный выхлоп в котором нет всей той информации которая нужна для VLIW.

Но у них (как ты сказал) «своя архитектура» очень сильно подстроенная под x86, ppc и arch64. Последний, возможно и стал таким похожим на x86 (если сравнивать с оригинальными armv6/v7), что бы llvm не игнорировал фичи процессора вроде тумбы или предикатов потому что они не похожи на то что в интеле есть.
В llvme например нету флагов-предикатов там есть один кондишн, который как раз ложится на интеловские условные jmpe cmov итп.

У нас уже есть пример прикручивания бекенда от LCC к LLVM силами самого МЦСТ с трансляцией промежуточного слоя. Как видим, архитектурно ничего особо не мешает, и условие LLVM в том, чтобы задачи LLVM решались средствами самого LLVM, а не сторонними проектами. То есть, достаточно аккуратно доработать промежуточный слой и вмержить кодогенератор, всё. Было бы желание.

Впрочем, «было бы желание» - это в принципе про весь МЦСТ. Было бы желание - и закопали бы наконец тупиковый VLIW, направив ресурсы на RISC.

Ну это и есть альтернативный бакенд, но да хитро реализованый через отдельную библиотеку что не придерешься.

Проблема в том что сам по себе LLVM-IR это уже как бы испорченый (с точки зрения vliw) код, то есть фронтенд берет исходник и компилирует его вот в это представление которое по наполнению информацией сильно уступает тому что было в исходном коде. В логике LLVM вся вот эта языковая семантика нужна просто что бы проверять ошибки и выстраивать правильную последовательность операций, вот llvm-ir ее и генерирует, оно выглядит как макро-ассемблер и из него приходится чуть ли не восстанавливать обратно исходный код. Как пережатие уже пережатых данных с потерями, прагмы те же просто отсутствуют. Я хочу и могу подсказать компилятору что мой цикл предполагает квадраты на картинке не более 40-60 пикселей больше просто на экране не будут помещаться, но llvm-ir говорит *«я все понял, цикл большой, разворачивать не буду, а бакенду это не нужно, родной, там цикл это просто условный прыжок в верх»*.

Поэтому в идеале надо что бы фронтенд просто выдавал сырое AST дерево с типами, бранчами итд. не знаю что мцст с этим делать намерено, но то что код не получается хорошим/оптимальным при вот этой их затычке они не могут не замечать

Директор по развитию МЦСТ (разработчика процессоров «Эльбрус») Константин Трушкин представил на совещании мини-ПК, который компания, по его утверждению, готова «переупаковать» в консоль.

В соседнем разделе уже создана под новость тема «Инновационная консоль на Эльбрусе», но все же скину сюда ссылку на хабр и скрин:

• В сети показали фото прототипа игровой приставки на базе «Эльбрус-2С3» под названием «Эльбрус 2C3 for gamers»
• https://ibb.co/ZS7Lf1c

Ожидается, что подобная игровая консоль на базе доработанного прототипа проекта «Эльбрус 2C3 for gamers» выйдет на рынок в 2028 году. Цена, по оценке комплектующих, будет начинаться от 50 тыс. рублей.

Тут неоднократно высказывались в пользу RISC-V, попалась статья на phoronix:

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

Интересно, как на эльбрусах обстоит с уязвимостями, учитывая, что там на «железном уровне» встроены защиты.

Это уязвимость конкретных китайских процессоров.

А вот интересно, компилятор такой же умный, как и CMS? Врядли, скорее всего сделали какое-то говно, так что тормозить должно сильнее чем в бинарной трансляции.

Вообще, скорее всего, собирать придется x86->VLIW, врядли LCC такой же умный как CMS у трансметы, лол.

что там на «железном уровне» встроены защиты.

такие как у интела?

Интервью Трушкина от 19.04.2024, Представлен МП21 -- одноплатный компьютер на базе процессора «Эльбрус-2С3» (комментарий).

Горшенин в своем телеграмме записал несколько «кружков» (короткое видео, типа шортса) с недавней выставки, где часто упоминает эльбрус.

August 13

«Российская техника имеет внутри недоверенный зарубежный процессор» Константин Трушкин, МЦСТ

Максим Горшенин, интервью с Константином Трушкиным, заместителем директора по маркетингу и развитию компании МЦСТ.
Первое (но не последнее) интервью с Константином про процессоры Эльбрус.
(August 29, 2024)

00:00 Мой начальник, Константин Трушкин, заместитель генерального директора по маркетингу и развитию
00:41 История появления моего канала на YouTube
01:08 Как сейчас с процессорами Эльбрус?
03:24 600 человек из МЦСТ переманил к себе Intel
04:10 Ким Александр Киирович, генеральный директор АО "МЦСТ"
04:50 Про СуперЭВМ Эльбрус-2
06:50 Жизнь МЦСТ после 2022 года. Сейчас есть процессоры Эльбрус в наличии?
08:27 Где сейчас работают компьютеры на Эльбрусах? ПВД НП МИР - загранпаспорта РФ
11:00 Китайские процы в TOP500 самых мощных компьютерах мира
11:48 K computer на базе SPARC-процессоров
12:19 МЦСТ и первый 64-битный процессор компании Sun Microsystems
14:30 Эльбрусы в системе ЦАФАП МВД РФ
15:37 Эльбрусы в Газпромбанке
18:48 Максим Копосов, директор компании Промобит, марка Bitblaze
20:48 Банкоматы на Эльбрусе
23:53 Почему JIT-компиляторы сложны для Эльбруса?
26:32 Процессор Эльбрус: плюсы/минусы?
29:15 Сколько государство вложило в Эльбрус?
30:15 Как идет разработка процессора в МЦСТ?
33:27 А как же Intel, AMD, ARM, RISC-V, etc..
35:11 Объёмы инвестиций Intel и ARM в  R&D ежегодно
36:39 Половина денег на разработку Эльбруса уходят за САПР и на фабрику производства
37:38 Российский САПР
38:09 МЦСТ и результат
38:40 Используешь российский проц - точно не "переклейка наклеек"
39:59 Подменя понятия "российское оборудование"
42:19 Реверс-инжиниринг процессоров
44:50 Intel Management Engine - официальный аппаратный бэкдор
45:17 Бэкдоры в Эльбрусах
46:15 Loongson - это то же советские наработки
46:23 Бэкдорами через "российскую" технику с зарубежным процессором насыщается рынок РФ
48:00 Режим безопасных вычислений Эльбруса
49:30 Отчет США по безопасности софта
51:25 Проект CHERRY Security
52:30 Эльбрус может помочь стране повысить киберстойкость софта (и под Intel тоже)
53:27 США готовятся к кибервойне
54:53 Что делать нам?
57:03 Как дела с Эльбрусом и физлицами?
57:35 Тот самый прототип игровой консоли на Эльбрус-2С3
01:01:11 Открытие исходников Эльбруса
01:04:23 Тема будущего ролика