Зачем нужна компиляция?

[Qlin]

Компиляционный процесс с помощью gcc включает в себя две обязательные фазы: компиляцию и ассемблирование. Я не понимаю, зачем нужна сама по себе компиляция. Вернее, почему бы сразу исходный или препроцессированный код не транслировать в объектный?

[Pavia]

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

Qlin в сообщении #1339844 писал(а):

Вернее, почему бы сразу исходный или препроцессированный код не транслировать в объектный?

Так и делается. Если делать через ассемблериование, то вы частично теряете отладочную информацию.
Плюс скорость компиляции будет меньше.

[aa_dav]

Pavia в сообщении #1339849 писал(а):

Если делать через ассемблериование, то вы частично теряете отладочную информацию.

Если с опцией -S смотреть в ассемблерный выхлоп (что я часто делаю), то там столько мишуры в виде отладочных макросов и символов видно (больше эффективного кода), что сомневаюсь, что там можно что-то потерять.
Непонятно даже зачем им убирать фазу ассемблера, ибо она компилируется мгновенно по сравнению с C/C++ и расходы на неё незначительны, чтобы её выкидывать, а ключ -S всё-равно делает её необходимой к реализации.
Так же если использовать директиву __asm и допустить внутри кода на ассемблере ошибку в ассемблерном коде, то прекрасно видно, что ошибки выводит процесс as так как __asm работает как макроподстановка текста с нехитрыми правилами для сшивания с имеющимся кодом и оптимизации (всегда балдел как элегантно эта штука у них работает).
В общем даже если эту фазу убрали в каких то случаях зачем то, то gcc всё равно ведет себя так как будто она есть и эту фазу можно всегда произвести явно - сгенерировать через -S файл .s и прогнав его через as получить бинарно идентичный файл как если бы компилировалось сразу через gcc. Сам проверял из любопытства пару лет назад на mingw.

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

[Qlin]

Pavia в сообщении #1339849 писал(а):

Так и делается

А где можно найти подтверждение? И когда было принято решение объединить две фазы в одну?

[dobrichev]

А может быть компилятор сложнее чем вы представляете?

GNU Compiler Collection (GCC) Internals

Если "фаза" имеет что-то общее с "pass", то т. 9 дает более подробную информацию что как делается.

Цитата:

Parsing pass: The language front end turns text into bits.
Gimplification pass: The bits are turned into something we can optimize.
Pass manager: Sequencing the optimization passes.
Tree SSA passes: Optimizations on a high-level representation.
RTL passes: Optimizations on a low-level representation.
Optimization info: Dumping optimization information from passes.

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

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