Нужен ли современным компиляторам ассемблер?

gcc вызывает as. Вы можете использовать gcc -v, чтобы увидеть, что он делает.

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

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

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

компилятор, ассемблер и компоновщик составляют цепочку инструментов, но компилятор, очевидно, не должен производить сборку. Это кажется более разумным/модульным решением, поскольку у вас есть ассемблер, и вы можете гораздо легче «увидеть» вывод компилятора, а не какое-то ведро битов (для этого потребуется еще один инструмент для отладки, инструмент, который для большинства isas предельно точно). но это не обязательно, и не каждый компилятор предназначен для использования шага языка ассемблера в качестве требования или опции.

многие, если не все компиляторы превращают язык высокого уровня в своего рода внутренний «код» или набор структур, который затем является промежуточным шагом к серверной части генерации целевого кода. llvm, например, что сама промежуточная информация может быть выведена в виде файла, имеет язык программирования и т. д., поэтому с clang/llvm вы можете иметь высокий уровень, байт-код, байт-код в форме ascii, язык ассемблера, объект и компоновщик или. ... вы можете перейти от высокого уровня к объектному коду, а затем связать. вы можете оптимизировать на каждом уровне.

(хотя вы получаете только один компоновщик, если он есть, хотя остальная часть цепочки инструментов способна создавать код для разных целей)

«Компилятору не нужен ассемблер, но автору компилятора может». Вариант «а» кажется высокомерным и нереалистичным. Большинство компиляторов могут выводить формы IR. Godbolt кто-нибудь использует? У компилятора может быть возможность перейти непосредственно к двоичному коду; но есть много случаев использования, когда возможность генерировать ассемблер является ценной. Я бы назвал компилятор, который не может генерировать ассемблер, неполноценным.

MSVC не использует отдельный ассемблер, и из того, что я читал, ассемблерные листинги, которые он может выдать, не готовы для сборки в полностью рабочие объектные файлы, которые вы могли бы связать. (например, они содержат посторонние определения, которые приведут к конфликтам имен.) Вот почему его параметр вывода asm называется «листинг». learn.microsoft.com/en-us/cpp/build/reference/…

Встроенный синтаксис __asm {} MSVC должен компилировать этот блок, а не просто передавать его ассемблеру. Или, по крайней мере, он должен проанализировать его на наличие имен переменных C++ и заменить их режимами адресации, а также знать, какие регистры записываются каждой инструкцией (так что он знает, что сохранять/восстанавливать в функции, содержащей блок asm). По этой причине встроенные ассемблерные блоки MSVC не поддерживают полный материал MASM, например. нет db для генерации произвольного машинного кода и IDK, если вы можете определить метки для выполнения сумасшедших вещей, таких как переход между операторами asm (что-то, что возможно, но не поддерживается для GCC).

IIRC, clang по умолчанию использует встроенный ассемблер и обрабатывает каждый оператор GNU C asm() отдельно, а не как часть одного большого файла. IIRC вы не можете определить .macro в одном и использовать его в другом, если вы не используете clang -fno-integrated-as

Мое понимание решения MSVC не поддерживать его ни на чем, кроме x86, заключается в том, что внутренняя реализация действительно хрупкая и сложная в обслуживании, а также небезопасна в функциях с регистровыми аргументами (даже на x86). И это никогда не было очень хорошим дизайном, заставляющим сохранение/перезагрузку для получения данных в операторе asm. Предоставление встроенных функций для всего лучше, чем неэффективный встроенный ассемблер. Также, вероятно, многие люди ожидали, что смогут делать сумасшедшие вещи за спиной компилятора.

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

Связанный: rust-lang.github.io/rfcs/… обсуждается тот факт, что синтаксис MSVC __asm { .. } в основном представляет собой предметно-ориентированный язык, встроенный в C++, который компилятор должен понимать для компиляции такого кода. (В отличие от встроенного ассемблера GNU C, который представляет собой просто %operand подстановку строки в шаблон и выдачу этого текста буквально в вывод ассемблера компилятора для сборки.) И что желательно не писать новый DSL для каждой поддерживаемой Rust архитектуры.

Еще одно преимущество компиляции непосредственно в машинный код: если вы используете ассемблер, «вы никогда не знаете, куда он поместит вещи, поэтому вам придется использовать отдельные константы». web.archive.org/web/20180212083430/https://cboh.org/mel.txt