О чем новость-то?

Выход исправлений по ЛОРу никто не отслеживает, про них тут редко пишут. А информации для обсуждения в ОП ноль.

В выпуске представлено более 157 исправлений, среди них 48 исправлений для компилятора C++, 47 - для компилятора Fortran и 16 - для libstdc++.

long live c++! обеспечивает работой кодеров проекта

О чем новость-то?

Выход исправлений по ЛОРу никто не отслеживает, про них тут редко пишут. А информации для обсуждения в ОП ноль.

Выход обновления важного для инфраструктуры линюкс проекта.

О всякой никчёмночти в виде rust, python, и т.д и т.п. конечно лучше не писать.

Фортран-то примерно на том же уровне.

Это который профессор?

Вопрос к знатокам

В GCC последней стадией компиляции чистосишного исходного кода является перевод ассемблерного кода в машинный (бинарный) код. Я знаю что GNU_assembler является частью пакета binutils.

В этом конкретном случае, для трансляции ассеблерного кода вызывается GNU_assembler из binutils или имеется встроенный GNU_assembler в самом GCC?

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

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

В этом конкретном случае, для трансляции ассеблерного кода вызывается GNU_assembler из binutils или имеется встроенный GNU_assembler в самом GCC?

gcc -v в помощь

Но gcc же генерирует именно ассемблер на выходе. Уже после пачки внутренних представлений.

Насколько я понимаю там ассемблерный выхлоп возможен только с флагом. Вроде как через ассемблер он работал в бородатые годы…

Насколько я понимаю там ассемблерный выхлоп возможен только с флагом. Вроде как через ассемблер он работал в бородатые годы…

Незнаю как там, но лично твоё стремление всем показать, что ассеблер это что-то устаревшее, НЕУБЕДИТЕЛЬНО. Финальная стадия компиляции, когда мнемоники ассемблера прямо переводятся в машинный код, это ПРАВИЛЬНО!

Ну наконец-то. Пришел анон и пояснил всем, как правильно.

LLVM ориентирован на определенную архитектуру процессоров. Опираться только на LLVM несерьезно. Те же эльбрусовцы твердят, что LLVM не подходит под их архитектуру.

мнемоники ассемблера прямо переводятся в машинный код, это ПРАВИЛЬНО

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

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

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

GCC имеет восемь фронтендов: чистый Си, Cи-плюс-плюс, Ди, Ада, Фортран, Обжектив-Си, Гоу, Бриг. Представь себе как глупо будет переводить куски синтакиса каждого из этих восьми ЯП прямо в машинный код. Объективно проще и логичнее было бы синтакис каждого из этих восьми языков перевести в некий «промежуточный код». Для GCC, GNU_assembler является полноценым бэкэндом, а не промежуточным кодом.

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

GCC имеет восемь фронтендов: чистый Си, Cи-плюс-плюс, Ди, Ада, Фортран, Обжектив-Си, Гоу, Бриг. Представь себе как глупо будет переводить куски синтакиса каждого из этих восьми ЯП прямо в машинный код. Объективно проще и логичнее было бы синтакис каждого из этих восьми языков перевести в некий «промежуточный код». Для GCC, GNU_assembler является полноценым бэкэндом, а не промежуточным кодом.

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

Для GCC, GNU_assembler является полноценым бэкэндом, а не промежуточным кодом.

Ну так я именно об этом и говорил. Вот только промежуточный код обязан быть чем-то вроде

struct BinaryOp
{
  enum class Kind
  {
    PLUS,
    MINUS,
    ...
  };

  Kind kind;
  Operand* a;
  Operand* b;
  Target* r;
};

+ сериализация на диск для удобства.

Вот только промежуточный код обязан быть чем-то вроде

Так стоп! У меня вопрос, а зачем вообще нужен дополнительный промежуточный код, зачем эта лишняя прослойка? Ведь есть же полноценный и ЗРЕЛЫЙ бэкэнд. GNU_assembler имеющий AT&T-синтаксис даже древнее чем процессоры Интел. Возражения о том, что язык ассемблера трудно читать, не принимаются.

Так стоп! У меня вопрос, а зачем вообще нужен дополнительный промежуточный код, зачем эта лишняя прослойка? Ведь есть же полноценный и ЗРЕЛЫЙ бэкэнд. GNU_assembler имеющий AT&T-синтаксис даже древнее чем процессоры Интел. Возражения о том, что язык ассемблера трудно читать, не принимаются.

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

Под видом анонимусов скрываются несведущие постояльцы ЛОРа:

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

С каких это пор as начал что-то оптимизировать-то? Его задача ДОСЛОВНО перевести написанное в маш. инструкции и ни шагу в сторону.

Хотя есть и более адекватные анонимусы:

GNU_assembler имеющий AT&T-синтаксис даже древнее чем процессоры Интел. Возражения о том, что язык ассемблера трудно читать, не принимаются.

И что бы доказать его правоту выдержка из man 1 as: «as is primarily intended to assemble the output of the GNU C compiler „gcc“ for use by the linker „ld“.»

то придётся эти оптимизации вкорячивать для каждой архитектуры отдельно.

А как иначе раскрыть рекурсии, заинлайнить короткие циклы, убрать ненужные конструкторы/деструкторы и ещё толпа чего. Всё это зависит от используемого языка ещё на этапе лексического разбора. Оптимизация под «машину» проводится перед «байткодом» в виде ассемблера.

Ну зачем они до сих пор мучают фортран?

что там полезного, в новом релизе?

А с -pipe и на /tmp забьет

С лажу с видимостью в d, из-за которой невозможно gtkd собрать так и не пофиксили

1. Для меня пофиксили 2 бага с редкоиспользуемыми «attribute»? lowlevel язык, потому уже годно.
2. Толпа багфиксов в C++ - очень годно, компилеры не успевают за развитием этого комбайна (из программеров - то же редкость, кто бы юзал C++17 на всю катушку, и при этом понимал, имел профит)

Затем,что нужно толпу кода из фортрана и ады перевести на что-то современное, и есессно знать как оно работает, что бы сравнивать результат рефакторинга.

Данный процесс ещё на полпути. Особенно в крупном бизнесе, когда от кода зависишь не ту, а твои клиенты…

З.Ы. А может тупо перекомпилить под новое железо…

Вопрос был не в этом. Вопрос в том, будет ли вызван ассемблер, и что вот это вот такое:

Вроде как через ассемблер он работал в бородатые годы…

Ответ: ассемблер будет вызван, а отквоченное - безграмотная лажа.

Ну наконец-то. Пришел анон и пояснил всем, как правильно.

Та аноним уж 20 лет как самый полезный пользователь лорчика

У гцц есть фронтенд, бэкенд, а между ними мидленд, но это не ассемблер для железа насколько мне известно. Вообще исходники открыты, возьми посмотри, потом расскажешь.

с++17 стал «неэкспериментальным» только в гцц9, и до сих пор для некоторых платформ он поддерживается не полностью, в продакешене его используют только васяны.

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

С каких это пор as начал что-то оптимизировать-то? Его задача ДОСЛОВНО перевести написанное в маш. инструкции и ни шагу в сторону.

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

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

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

компилятор фортрана там же на C написан, насколько помню

компилятор фортрана там же на C написан, насколько помню

Хе-хе_хе, «Говорим UNIX подразумеваем Си, говорим Си подразумеваем UNIX».

Весь GCC написан на Си и Си-плюс-плюс. Изначально он был целиком написан на чистом Си. С какой-то там версии добавили исходники на Си-плюс-плюс. На форумах то время начались громкие возмущения: «безобразие, какого чёрта, нафик туда плюсы пихнули, зачем усложнять, зачем вообще в компиляторе этот ООП язык». Короче около GCC-шное сообщество не любило C++.

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

Вот недавно в Glibc пихнули фрагменты исходников на Python. А Glibc, на минуточку не больше не меньше реализация стандартной библиотеки языка Си.

Согласен полностью. Про развитие «плюсов» отдельная тема для срача - много там наворочено, и в 11х и в 17х.

Хорошо, что меня это пока не касается - в плючах живу на уровне 2000х (чистый Си с плюсами)…

Я видать попутал анонимусов, т.к. отвечал именно на смысл «оптимизация на уровне ассемблера». Ну и в ГЦЦ, насколько я помню, нет никакого промежуточного кода - сразу в АСМ, а то, что у него там в памяти или в /tmp творится - даже богу неизвестно… Шланг - да, но там всё иначе, хоть и выглядят для разраба одинаково…

Возражения о том, что язык ассемблера трудно читать, не принимаются.

Ты не поверишь, беда в том, что его трудно писать из программы, а не читать. Промазал палец мимо клавиши при наборе строки - ушла ошибка в релиз. Ну и как говорили остальные, ассемблер всегда процессорозависим. Как предлагаешь в армы и всякие там мипсы конвертить, не говоря уж о том, что 32 и 64 бита дают разный ассемблерный текст. У компилятора есть некоторое представление программы, надо которым он проводит серию преобразований (втч общие и процессоро-ориентированные оптимизации). Самое удобное представление сущности в коде - это некая структура данных. И только чтоб смотреть на нее глазом хумана можно сконвертить ее в некий текст, который вы так хотите назвать промежуточным представлением. А на самом деле - то просто отладочный вывод (+ формат сериализации, который может пригодиться только разработчикам компилятора и некоторым ценителям извращений)

Я чесно говоря не понял, по какой причине пихнули туда Си-плю-плюс

Заметили, какой век на дворе, вот и вся причина. LLVM разбудил.

Компилятор - сложнейшая высокоуровневая логика. Кому упало писать это на околоассемблере?

Весь GCC написан на Си и Си-плюс-плюс.

Не совсем так. Компилятор Ada, входящий в состав GCC, написан на Ada. И для своей сборки требует либо одну из предыдущих версий GCC-Ada, либо, например компилятор Ada от Adacore.

Насколько я понимаю там ассемблерный выхлоп возможен только с флагом. Вроде как через ассемблер он работал в бородатые годы…

Ты заблуждаешься. Если во время компиляции ты запустишь условный top, то увидишь, как часто там вызывается as из binutils.