LINUX.ORG.RU

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

 , ,


4

5

Компания МЦСТ открыла веб-портал dev.mcst.ru для разработчиков ПО на платформе Эльбрус, где публикует исходные тексты и патчи.

На данный момент опубликованы:

  • исходный текст ядра Linux для архитектуры Эльбрус;
  • исходный текст библиотеки glibc для архитектуры Эльбрус;
  • набор патчей для оригинальных исходных текстов прикладных пакетов дистрибутива Эльбрус Линукс.

Также на портале доступны для скачивания учебные материалы и руководства для программистов, собраны ссылки на ресурсы и сообщества, посвященные тематике платформы Эльбрус. Через форму запроса можно подать заявку на получение удаленного доступа к серверам Эльбрус.

>>> Подробности

★★★★★

Проверено: shell-script ()
Последнее исправление: shell-script (всего исправлений: 2)
Ответ на: комментарий от x22

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

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

IvGrad
()
Ответ на: комментарий от Second_Variety

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

uin ★★★
()
Ответ на: комментарий от jpegqs

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

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

uin ★★★
()
Ответ на: комментарий от liksys

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

uin ★★★
()
Ответ на: комментарий от uin

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

liksys ★★★★
()
Ответ на: комментарий от liksys

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

uin ★★★
()
Ответ на: комментарий от uin

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

liksys ★★★★
()
Ответ на: комментарий от liksys

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

uin ★★★
()
Ответ на: комментарий от uin

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

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

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

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

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

uin ★★★
()
Ответ на: комментарий от uin

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

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

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

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

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

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

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

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

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

uin ★★★
()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от uin

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

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

liksys ★★★★
()
Ответ на: комментарий от liksys

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

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

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

uin ★★★
()
Ответ на: комментарий от IvGrad

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

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

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

krasnh ★★★★
()

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

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

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

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

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

uin ★★★
()

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

anon1984
()

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

anon1984
()

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

August 13

krasnh ★★★★
()

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

Максим Горшенин, интервью с Константином Трушкиным, заместителем директора по маркетингу и развитию компании МЦСТ.
Первое (но не последнее) интервью с Константином про процессоры Эльбрус.
(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 Тема будущего ролика
krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

Максим Горшенин. Второе обещанное интервью с Константином Трушкиным.
(22.09.24)

САМЫЕ НЕУДОБНЫЕ ВОПРОСЫ К РАЗРАБОТЧИКАМ ЭЛЬБРУСА! Константин Трушкин, МЦСТ

00:00 Вступление
00:28 Ядро Linux на Эльбрус и Безопасный режим
05:25 Можно ли получить удалённый доступ к машине с защищенным режимом?
06:59 Можно ли сделать Эльбрус на Микроне в России на 90 нм?
10:17 Зачем нам 7 нм, когда можно сделать тот же самый проц на 90 нм и пусть будет больше!
13:42 Критика Эльбруса от Pro Hi-Tech
18:57 Про стоимость Эльбрусов ЗДЕСЬ
20:08 Способна ли МЦСТ заполнить потребности рынка?
25:44 КасперскийОС и Аврора на Эльбрусе. Игровая консоль на Эльбрусе
28:16 Сетевое оборудование и NGFW имеется?
30:30 Эльбрус не подходит для бизнес-задач?    
32:03 Экономика Эльбрусов
35:39 Ответ на вопрос про технологию работы Эльбрусов
40:22 Префетчеры в Эльбрусах
43:01 О технологии out-of-order
47:23 Суперкомпьютерные вычисления на Эльбрусе 8 поколения?
49:37 Повышение эффективности для бизнес-приложений
50:49 Сообщество потребовало. Эльбрус открыл
53:04 Не выложили компилятор! Когда?
55:07 Есть ли спрос на Эльбрусы?
57:13 Зачем нужен Эльбрус, когда есть RISC-V
01:01:03 Суверенитет России с RISC-V
01:03:37 Итог: Присоединяйтесь к развитию процессора Эльбрус
krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

Попробую угадать ответы перед просмотром.

06:59 Можно ли сделать Эльбрус на Микроне в России на 90 нм?

Нельзя. Микрон не потянет, а готовые процессоры никто массово не купит.

10:17 Зачем нам 7 нм

Чтобы хоть как-то с кем-то конкурировать и хоть что-то эффективно заменять.

18:57 Про стоимость Эльбрусов ЗДЕСЬ

Десятикратный ценник. И то, если найдётся крупный рукопожатный заказчик.

53:04 Не выложили компилятор! Когда?

Никогда, очень секретно.

57:13 Зачем нужен Эльбрус, когда есть RISC-V

Наше, не наше. Консорциум в США будет усложнять жизнь.

neumond
()
Последнее исправление: neumond (всего исправлений: 1)
Ответ на: комментарий от neumond

Не выложили компилятор! Когда?

Никогда, очень секретно.

Трушкин посетовал в интервью, что вот 3 месяца, как выложили исходники и ни одного(!) коммита за все это время от так называемого опенсорс-сообщества. А ведь столько разговоров было, типа, дайте и как все завертится… )

И добавил, что исходники компилятора, ведь, на порядок сложнее, но желающие могут связаться по контактам (показаны в видео) и им будет предложена форма взаимодействия, устраивающая всех.

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

Это всё здорово. Но я не хочу стать невыездным только потому что мне любопытно и хочется помочь. Они даже для системы команд процессора требуют NDA подписать. Если меня освободят от всей этой юридической чепухи, позволят купить хоть какую-то железку, то я вполне не против с ней повозиться. Но это будет примерно никогда, проще китайцев купить, там и лоонгсоны есть, и ноутбук на риск5 вышел.

neumond
()
Ответ на: комментарий от krasnh

И добавил, что исходники компилятора

Следующий шаг, который мы планируем в течении этого года, это выложить бинарники компиляторов… (c)

krasnh ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.