LINUX.ORG.RU

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

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)

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

Deathstalker ★★★★★ ()

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

devl547 ★★★★★ ()

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

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

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

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

I-Love-Microsoft ★★★★★ ()

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

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

Ну как пилят… 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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

которых ни в gcc

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

AS ★★★★★ ()
Ответ на: комментарий от no-such-file

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

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

AS ★★★★★ ()
Ответ на: комментарий от no-such-file

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

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

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

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

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

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

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

Deleted ()

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

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

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

alexanius ()
Ответ на: комментарий от Deleted

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

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

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

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

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

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

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

alexanius ()
Ответ на: комментарий от Deleted

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от alexanius

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

alexanius ()
Ответ на: комментарий от Stil

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

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

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

alexanius ()
Ответ на: комментарий от Deleted

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от alexanius

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

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

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

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

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

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

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

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

ЛПиП

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Deleted

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

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

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

anonymous ()
Ответ на: комментарий от legolegs

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от anonymous

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

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

alexanius ()
Ответ на: комментарий от Evgueni

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

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

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

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

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

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

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

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

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

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

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

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

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

alexanius ()
Ответ на: комментарий от timdorohin

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

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

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

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

alexanius ()
Ответ на: комментарий от vaddd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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