GCC для «Эльбруса»

Даже если собрать, что им потом делать ? Кросскомпиляцией заниматься ? Потому как сам gcc для Эльбруса собирать не умеет пока, там надо архитектуру добавлять, а это целая история. В BaseALT пилят сборку ALT для E2K, может быть, там что-то известно про GCC. Но пилят пока эльбрусовским компилятором, не gcc.

C такими вопросами лучше в службу поддержки обращаться.

Собрать можно. Собирать GCC бинарники для Эльбруса - нет, у МЦСТ свой форк.

Берёшь LLVM. Собираешь.

В BaseALT пилят сборку ALT для E2K, может быть, там что-то известно про GCC. Но пилят пока эльбрусовским компилятором, не gcc.

Ого, это интересно. Alt как-то не очень на фоне Ubuntu для меня, но вполне годный дистр будет на Эльбрусах! И обновляться чаще, софт свежее чем МЦСТ делает...

Система команд эльбруса закрытая (или, по крайней мере, МЦСТ не потрудились её задокументировать), поэтому создать GCC, спосодный делать бинарники для эльбруса нельзя.

Ну как пилят… https://forum.altlinux.org/index.php?topic=37732.0

Ну как пилят… https://forum.altlinux.org/index.php?topic=37732.0

Ну так пилят... Практически одновременно это опроверг Шигорин. То ли днём раньше, то ли днём позже, но не на форуме ALT, а то ли в ЖЖ, то ли на «сделаноунас». Я две ссылки одновременно как-то постил на LOR. Недавно вот пролетело у collectd:

 2017-07-01 Michael Shigorin <mike at altlinux.org> 5.5.2-alt1.3

    - E2K: insist it's -std=c99, see e.g. cpu.c::cpu_commit_one();
    thanks imz@ and MCST guys for investigation

Система команд эльбруса закрытая

Там вообще принципиально другая организация команд и тегированная память - нужны соответствующие алгоритмы кодогенерации, которых ни в gcc, ни в llvm нет и не будет.

которых ни в gcc

В теории, для IA64 должно быть что-то похожее. Вопрос - на сколько.

что-то похожее

Разве там была тэгированная память?

Разве там была тэгированная память?

Не знаю. Я исходя из архитектуры.

Ну как пилят…

Вот ещё чуть-чуть: https://www.altlinux.org/Ports/e2k
Все правки странички этого года.

нужны соответствующие алгоритмы кодогенерации, которых ни в gcc, ни в llvm нет и не будет

Если бы разработчики Эльбруса не страдали NIH-синдромом, то они бы там были =).

И вообще, других запиливателей новых архитектур в llvm и gcc как-то не останавливало отсутствие там чего бы то ни было. И я ни разу не поверю, что Эльбрус отличается от других архитектур достаточно сильно, чтобы сделать поддержку его в gcc/llvm невозможной, но недостаточно для того, чтобы сделать невозможным портирование линукса.

Они говорили, что натянуть язык llvm на систему команд эльбруса можно, но важные фичи платформы на llvm невыразимы, поэтому получится плохо и медленно.

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

Возможно ли собрать GCC под «Эльбрус» и сильно ли напряжное/геморное это занятие?

Возможно (по крайней мере старые версии). Только вот не нужно. Бэкенда под Эльбрус всё равно нет, а собирать на нём коды для Интел - удовольствие сомнительное.

Если имелось ввиду исользовать gcc как компилятор для Эльбруса, то его не существует и скорей всего никогда не будет. МЦСТ имеет собственный компилятор, а портировать gcc или llvm - никому не нужный изврат.

В том-то и дело, что не (только) NIH: если научить бекенд LLVM всему, что нужно для эльбруса, то он станет несовместим с бекендами для других архитектур. LLVM недостаточно абстрагирован от железа.

Что, эльбрус от интела отличается сильнее, чем AMDшные GPU от того же интела? Опять не верю.

Что, эльбрус от интела отличается сильнее, чем AMDшные GPU от того же интела? Опять не верю.

Правильно, верить не надо, надо почитать про Эльбрусы

В любом случае, на основе проектов типа llvm/gcc серьёзные промышленные компиляторы, конечно же, не пишутся

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

Немного поясню. Компилятору Эльбруса более 20 лет. Когда его создавали llvm даже в планах не было, а gcc был убог до неприличия. Была возможность использовать gcc (и вроде как даже порт под него был), но к счастью этого не сделали.

Почему так делать нельзя:

• gcc ориентируется на RISC машины, и не предназначен для VLIW. Его тупо нельзя сделать эффективным
• Постоянные неконтролируемые изменения. Если кто-то что-то поменяет в промежуточном представлении, то придётся переделывать все собственные оптимизации, а их дофига
• Никому не хочется разбирать ошибки китайских студентов, которые накоммитят говна в gcc, а его там предостаточно

Правильно, верить не надо, надо почитать про Эльбрусы

За ссылку спасибо.

В любом случае, на основе проектов типа llvm/gcc серьёзные промышленные компиляторы, конечно же, не пишутся

И чем же «серьёзные промышленные компиляторы» отличаются от тех, которыми пользуется весь остальной мир? И что же это вообще такое?

И чем же «серьёзные промышленные компиляторы» отличаются от тех, которыми пользуется весь остальной мир? И что же это вообще такое?

Во-первых наличием поддержки. Во-вторых надёжностью.

Если с первым очевидно, то второе надо раскрыть. Основная идея VLIW в том что все оптимизации делает компилятор, а значит компилить софт с опциями меньше чем -O3 не желательно. Так вот, gcc на этих опциях просто разваливает софт. Он начинает некорректно работать, сегфолтиться на ровном месте и т.д. Часто это из-за того что софт кривой, но в случае с gcc - он делает это даже на обычных бенчмарках.

Дистрибутив ОС Эльбрус по дефолту собирается с опцией -O3, и вполне себе работает. Не без ошибок, но на этом действительно можно работать. Чего не скажешь о генте, собранной с -O3.

gcc ориентируется на RISC машины, и не предназначен для VLIW. Его тупо нельзя сделать эффективным

А что делать с LLVM?

Постоянные неконтролируемые изменения. Если кто-то что-то поменяет в промежуточном представлении, то придётся переделывать все собственные оптимизации, а их дофига

Почему остальным это не мешает?

Никому не хочется разбирать ошибки китайских студентов, которые накоммитят говна в gcc, а его там предостаточно

А кому хочется напарываться на баги проприетарного компилятора, которым пользуются полтора человека во всём мире?

На самом деле, я бы скорее поверил в то, что тотальная закрытость всего (включая документацию для разработчиков) и отсутствие желания добавлять поддержку в существующие открытые проекты - это требование военных, а не какое-то техническое ограничение. Со стороны это выглядит именно так. Ну и, в качестве вишенки на торте, кроме отсутствия доступных средств разработки - отсутствие нормальной ОС. Вместо неё, в духе лучших китайских производителей SoC'ов на ARM'е, ядро очень странной версии с китайскими российскими патчами =).

В любом случае, на основе проектов типа llvm/gcc серьёзные промышленные компиляторы, конечно же, не пишутся

Расскажи мне больше, пожалуйста.

но в случае с gcc - он делает это даже на обычных бенчмарках

Не вижу в посте ссылки на багрепорты. Все виденные лично мной случаи поломки кода при компиляции gcc с -O3 происходили из-за того, что исходники состояли из UB через строчку.

Дистрибутив ОС Эльбрус по дефолту собирается с опцией -O3, и вполне себе работает. Не без ошибок, но на этом действительно можно работать.

Очень странно сравнивать -O3 у совершенно разных компиляторов, не имеющих общей кодовой базы. Где-нибудь точно существует компилятор, у которого -O16 является валидной и совершенно безопасной опцией 8).

Чего не скажешь о генте, собранной с -O3.

Гента и гентоюзеры, у которых половина мана gcc в CFLAGS - это отдельный вопрос. Ну и код на C/C++ за пределами крупных проектов - в основном очень низкокачественный.

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

gcc ориентируется на RISC машины, и не предназначен для VLIW. Его тупо нельзя сделать эффективным

А что делать с LLVM?

А зачем с ним что-то делать? Точнее, сейчас llvm стал частью некоторых проектов типа mesa, и это добавляет хлопот, но бэкенд для него делать совершенно не нужно.

Почему остальным это не мешает?

Мешает, можно посмотреть соседнюю тему. Опять же, зачем llvm когда есть свой отличный компилятор? А llvm, к примеру, ещё и fortran не умеет, всё через какие-то костыли. Про создание бэкенда llvm где-то на хабре разработчики мультиклета плевались.

А кому хочется напарываться на баги проприетарного компилятора, которым пользуются полтора человека во всём мире?

Пользователям какого-нибудь icc это пока что не мешает. Багов у компилятора Эльбруса меньше чем у «качественных открытых проектов» ;) А уж исправляются они гораздо быстрее )

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

Если бы дело было в закрытости - можно было бы взять gcc, доработать и никому не давать ;) На самом деле в компиляторе действительно есть вещи типа особенностей работы аппаратуры, которые не хотелось бы публиковать, но в данном случае здесь больше технических и маркетинговых причин.

Со стороны это выглядит именно так. Ну и, в качестве вишенки на торте, кроме отсутствия доступных средств разработки - отсутствие нормальной ОС. Вместо неё, в духе лучших китайских производителей SoC'ов на ARM'е, ядро очень странной версии с китайскими российскими патчами =).

Обычный linux с изменённой arch частью. Где-то в интернетах даже сами патчи были. Но вообще у пользовательей есть всё что на данный момент портировано. Другой вопрос - взаимодействие с сообществом, но тут всё несколько сложнее, да.

В любом случае, на основе проектов типа llvm/gcc серьёзные промышленные компиляторы, конечно же, не пишутся

Расскажи мне больше, пожалуйста.

Не вопрос. Самый близкий пример - это icc. У них свой самобытный компилятор. Далее Sun (Oracle) - тоже самое. Смотрим в IBM - и опять проприетарщина!

Не вижу в посте ссылки на багрепорты. Все виденные лично мной случаи поломки кода при компиляции gcc с -O3 происходили из-за того, что исходники состояли из UB через строчку.

Пытался разок (правда на sanitizer). Но разбирать runtime ошибки в проекте, которым не занимаешься долго и сложно. Особенно если не можешь предоставить исходник, на котором падает. Не осилил, короче.

Очень странно сравнивать -O3 у совершенно разных компиляторов, не имеющих общей кодовой базы. Где-нибудь точно существует компилятор, у которого -O16 является валидной и совершенно безопасной опцией 8).

Справедливо, но в данном случае сравнение относительно корректное. По крайней мере в случае с gcc мне приходилось сбрасывать опции до -O1, а разок даже до -O0 чтобы заработало.

Гента и гентоюзеры, у которых половина мана gcc в CFLAGS - это отдельный вопрос.

Если мне не изменяет память, то у меня там только -O3 и было. Так вот, у меня vim давал segfault прям при запуске. Причём здесь я готов поверить что это vim кривой. Но на штатных бенчмарках (SPEC CPU 2006) мне приходится на некоторых тестах занижать уровень оптимизаций.

Пользователям какого-нибудь icc это пока что не мешает.

Ну ты сравнил. Пользователей icc сильно больше.

Багов у компилятора Эльбруса меньше чем у «качественных открытых проектов» ;) А уж исправляются они гораздо быстрее )

Неуловимый Джо.

Ну ты сравнил. Пользователей icc сильно больше.

Т.е. из-за малого количества пользователей нужно не писать свой компилятор, а срочно переносить 20 лет разработок на чужой компилятор?

Не вопрос. Самый близкий пример - это icc. У них свой самобытный компилятор. Далее Sun (Oracle) - тоже самое. Смотрим в IBM - и опять проприетарщина!

GCC/LLVM компилируют под те же архитектуры, что и эти проприетарные компиляторы. Просто немного хуже. А многим удобство использования важнее выдавливания максимума из платформы.

Ты пойми, претензия не к тому, что под эльбрус существует свой проприетарный компилятора. Тут всё в порядке. Проблема в том, что альтернативы ему нет. И она никогда не появится по инициативе «со стороны».

Мне просто обидно, что потенциально интересную российскую разработку ждёт очень грустная судьба - она сгниёт в застенках российской военщины, так и не найдя полезного применения.

Т.е. из-за малого количества пользователей нужно не писать свой компилятор, а срочно переносить 20 лет разработок на чужой компилятор?

Писать свой компилятор, если есть желание и ресурсы. И переносить 20 лет разработок на «чужой компилятор». Это кстати очень взаимовыгодно: в обмен будет получена поддержка всех языков программирования, фронтэнд для которых есть для этого «чужого компилятора».

Если этого не делать, то возникнут неожиданные проблемы, вроде невозможности собрать следующий ESR-релиз браузера или какую-нибудь очень распространённую тулзу для управления контейнерами =).

Мне просто обидно, что потенциально интересную российскую разработку ждёт очень грустная судьба - она сгниёт в застенках российской военщины, так и не найдя полезного применения.

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

Чего не скажешь о генте, собранной с -O3.

ЛПиП

Сидел на генте с -O3 везде, кроме 5 кривых пакетов. Не собираются они не по вине компилятора, а по вине криворуких пейсателей. Попробуй найди хоть один проект соответствующий c99, который бы не собрался с -O3, вот тогда и можешь говорить про компилятор.

Есть, конечно, багнутые версии компилятора, но там уж не собирается что угодно...

И кстати, ядро прекрасно работает с -O3, тоже проверено.

Полузакрытые военные проекты

Это и называется сгниёт. Поставят систему в уголке и будут на неё молиться, чтобы не сдохла. На этом всё развитие закончится.

btw, ORC и девиации рассматривали?

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

gcc имеет некоторую поддержку vliw, но я так понимаю шедулинг инструкций там ограничен бэйсик блоком, а для такого широкого vliw как эльбрус это совсем ничего. А все потому что vliw в gcc представлен second-class таргетами, грубо говоря на на них кладут если для них генерируется субоптимальный код...

зы мимокрокодил, ни разу не ыксперт

llvm вообще натягивается с трудом на что угодно отличающееся от тупого 486. я в свое время забил делать компилятор для своего проца из llvm(чтоб проверить на реальном софте как в симуляторе будут клоки тратиться) потому что эта цука! крахается в ряде плагинов если не размапить все регистры в физические. в nvptx это обходят в ручном режиме кстати, но оно все равно кусается.

btw, ORC и девиации рассматривали?

Не знаю, но сомневаюсь. Не факт что он в то время уже существовал. Но вообще тогда шло сотрудничество с Sun, и странно было бы развивать проекты, связанные с Intel.

Вы неправы. Если проект не попал к каждому школьнику или в каждый офис - это не называется сгнить. Это полноценная жизнь в отдельном пространстве. Военная техника (в какой бы стране ее не разрабатывали) всегда мало пересекалась с массовыми (не)коммерческими изделиями. Так и должно быть.

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

GCC/LLVM компилируют под те же архитектуры, что и эти проприетарные компиляторы. Просто немного хуже. А многим удобство использования важнее выдавливания максимума из платформы.

Это если есть сообщество, готовое их развивать. С Эльбрусами пока что не так. Ну и тут проблема в том что в случае с VLIW это будет не «немного хуже», а неприлично плохо - это такая техническая особенность.

Проблема в том, что альтернативы ему нет. И она никогда не появится по инициативе «со стороны».

Ну тут примерно следующая ситуация. Я думаю что есть подмоножество системы команд, которое можно было бы раскрыть, но созданием открытого бэкенда МЦСТ заниматься не будет т.к. это сложно, долго и дорого, а прибыли не принесёт. В данном случае гораздо выгодней выложить бинарь собственного компилятора - это совершенно реальный сценарий.

Мне просто обидно, что потенциально интересную российскую разработку ждёт очень грустная судьба - она сгниёт в застенках российской военщины, так и не найдя полезного применения.

Надеюсь что нет :) По крайней мере в гос. сектор продукция проходит, там и до обычных пользователей не далеко.

Это кстати очень взаимовыгодно: в обмен будет получена поддержка всех языков программирования, фронтэнд для которых есть для этого «чужого компилятора».

Тут соглашусь только на половину :) Портировать фронтенд гораздо проще - т.е. получить поддержку языков оставляя старый бэкенд. А вот перенос бэкенда скорей всего технически не возможен. Компилятор - это проект на несколько миллионов строк кода со своей уникальной инфраструктурой. Там даже внутреннее представление сильно различается. По сути это означало бы взять все алгоритмы и переписать с нуля. В итоге получится куча ошибок и просадки производительности. Преимущества непонятны.

Если этого не делать, то возникнут неожиданные проблемы, вроде невозможности собрать следующий ESR-релиз браузера или какую-нибудь очень распространённую тулзу для управления контейнерами =).

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

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

Я не говорил что они не собираются, я говорил что они падают в произвольных местах. Готов поверить что это кривость софта, но я знаю примеры кривости именно gcc. В любом случае я не смог сидеть на генте -O3 именно из-за её нестабильности.

И кстати, ядро прекрасно работает с -O3, тоже проверено.

А в это тупо не верю, т.к. такой концентрации говнокода надо поискать. Как минимум их система сборки должна была отключать что-то на подобии strict-aliasing чтобы оно не упало вообще сразу. Т.е. это уже не базовый -O3.

В момент когда умирают или деквалифицируются носители знаний технология отходит с концами. Когда носителей полтора кекса, то технология уже при смерти. Как они отъедут в Германию — новых не найдётся.

Я не разбирался, какие флаги отключает система сборки, я просто в Makefile поправил -O2 на -O3 (в глобальном, ес-нно)

Единственное, что я помню - невидивский модуль не работал, хоть убей. А вот nouveau почему-то не падал...

Нет, военную продукцию так не разрабатывают ) Ситуаций, когда разработчиков полтора человека и они это носят в себе, в ВПК не бывает по определению. Там каждый шаг обсуждается, согласовывается, составляется план испытаний. Каждый этап строго документируется. Главный разработчик в ВПК только один - начальник. Все остальные - винтики с регламентированными функциями. Поэтому все эти «Эльбрусы» безнадежно отстают, но так везде.

Ну да. Примерно так гниение и выглядит. Живые програмные трупы.

Это подход кустаря-админа. Чего-то там слепить на коленке за полдня, заработало - хорошо. Не заработало или вылезли глюки - можно погуглить, спросить. А впк, космос - это все миллиарды денег и человеческие жизни в случае сбоя. Оно _должно_ быть максимально обстоятельным и заторможенным. Семь лет проверь, один раз сделай.

Я немного про другое говорю. И да, я видел во что превращаются «надёжные технологии» через десять лет. Заканчивается тем, что на замену прикупается ширпотреб, который внезапно оказывается надёжней.

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

Если в этот закрытый бэкэнд можно будет подсунуть произвольный IR, то это уже само по себе отлично.

А все потому что vliw в gcc представлен second-class таргетами, грубо говоря на на них кладут если для них генерируется субоптимальный код...

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