Из обсуждения где-то еще:
C++ не имеет стандартного ABI (бинарного интерфейса приложения).
Но и C тоже, верно?
На любой данной платформе это в значительной степени так. Он не был бы полезен в качестве лингва-франка для межъязыкового общения, если бы его не было.
Что вы думаете об этом?
C не определяет ABI. На самом деле, он из кожи вон лезет, чтобы избежать определения ABI. Те люди, которые, как и я, посвятили большую часть своей жизни программированию на C для 16/32/64-битных архитектур с 8-битными байтами, арифметикой с дополнением до 2 и плоскими адресными пространствами, обычно будут весьма удивлены, прочитав запутанный язык текущий стандарт C.
Например, почитайте про указатели. Стандарт не говорит ничего такого простого, как «указатель — это адрес», поскольку это было бы предположением об ABI. В частности, он позволяет указателям находиться в разных адресных пространствах и иметь разную ширину.
ABI — это сопоставление модели исполнения языка с конкретной комбинацией машины/операционной системы/компилятора. Нет смысла определять его в спецификации языка, потому что это может привести к исключению реализаций C на некоторых архитектурах.
CS, DS, ES или SS. Однако адреса на 8086 представляют собой 20-битные двоичные числа.
- person JeremyP; 04.01.2020
C в принципе не имеет стандартного ABI, но на практике это редко имеет значение: вы делаете то, что делает ваш поставщик ОС.
Возьмем, к примеру, соглашения о вызовах в x86 Windows: Windows API использует так называемое «стандартное» соглашение о вызовах (stdcall). Таким образом, любой компилятор, который хочет взаимодействовать с ОС, должен реализовать это. Однако stdcall поддерживает не все возможности языка C90 (например, вызов функций без прототипов, функции с переменным числом переменных). Поскольку Microsoft предоставила компилятор C, было необходимо второе соглашение о вызовах, называемое соглашением о вызовах 'C' (cdecl). Большинство компиляторов C в Windows используют это как соглашение о вызовах по умолчанию и, таким образом, совместимы.
В принципе, то же самое могло бы случиться и с C++, но поскольку ABI C++ (включая соглашение о вызовах) неизбежно является гораздо более сложным, поставщики компиляторов не договорились о едином ABI, но все же могли взаимодействовать, возвращаясь к extern "C".
ABI для C специфичен для платформы — он охватывает такие вопросы, как распределение регистров и соглашения о вызовах, которые, очевидно, специфичны для конкретного процессора. Вот некоторые примеры:
x86 имеет много соглашений о вызовах, какие расширения в Windows определяют, какое из них используется. ABI платформы для встроенного Linux также со временем изменились, что привело к несовместимости пользовательского пространства. См. некоторую историю переноса на ARM Linux здесь, которая показывает проблемы при переходе на более новую ABI.
ABI, даже для C, имеет части, которые совершенно не зависят от платформы, части, которые зависят от процессора (какие регистры должны быть сохранены, какие используются для передачи параметров,...) и части, которые зависят от ОС (более или менее те же факторы, что и для процессора, поскольку некоторые варианты выбора не навязываются архитектурой, а являются результатом компромиссов, плюс некоторые ОС имеют понятие исключения, не зависящее от языка, и поэтому компилятор для любого языка должен генерировать то, что нужно обрабатывать в этом случае обработка потоков также может накладывать некоторые вещи на ABI — если регистр указывает на TLS, вы не можете использовать его для того, что хотите).
Теоретически у каждого компилятора может быть свой собственный ABI. Но обычно для пары процессор/ОС ABI фиксируется поставщиком ОС, который часто также предоставляет компилятор C и общие библиотеки, которые используют этот ABI, и конкуренты предпочитают быть совместимыми. (Я не удивлюсь, если есть исключения для некоторых ОС, для которых C не является основным языком программирования).
Но поставщик ОС может переключить ABI по той или иной причине (новые версии процессоров могут иметь функции, которые вы хотите использовать в ABI для одной — например, некоторые запросили 32-битный ABI для x86_64, позволяющий использовать все регистры) . На этапе миграции, который может занять очень много времени, вам, возможно, придется обрабатывать два ABI.
как и C, верно?
Правильно
На любой платформе это почти так и есть. Он не был бы полезен в качестве лингва-франка для межъязыкового общения, если бы его не было.
В значительной степени может относиться к значениям по умолчанию для конкретной архитектуры, выбранным поставщиками компилятора C, которые адаптируются для других языков. . Таким образом, если компилятор Keil ARM C будет использовать порядок параметров с прямым порядком байтов слева направо и стек для передачи аргументов и некоторый заранее определенный регистр для возвращаемого значения, тогда extern «C» из других компиляторов предполагает совместимость с такой схемой.
Хотя такое соглашение можно считать частью ABI, в отличие от контекста управляемого выполнения, такого как песочница браузера JVM, само по себе это далеко не полный стандартный ABI.
Хотя было предпринято несколько попыток определить единый ABI для данной архитектуры в нескольких операционных системах (в частности, для i386 в системах Unix), эти усилия не увенчались успехом. Вместо этого операционные системы, как правило, определяют свои собственные ABI...
Цитирование... Системное программирование Linux стр. 4.
C не имеет стандартного ABI. Это легко проиллюстрировать всеми соглашениями о вызовах (cdecl, fastcall и stdcall), которые там используются. Каждый из них представляет собой отдельный ABI.
До стандарта C89 компиляторы C для многих платформ использовали по существу один и тот же ABI, за исключением различий в размерах данных. Для машин, стек которых растет вниз, код, вызывающий функцию, помещает аргументы в стек по порядку справа налево, а затем вызывает функцию (помещая адрес возврата в процессе). Вызываемая функция оставляет свои аргументы в стеке, а вызывающая сторона на досуге настраивает указатель стека, чтобы удалить их [или, в некоторых архитектурах, может корректировать значения в стеке на месте]. В то время как <stdarg.h> избавил большинство программ от необходимости полагаться на это соглашение, оно использовалось в течение многих лет, потому что было простым и работало довольно хорошо. Хотя не было «официального» документа, устанавливающего, что это кроссплатформенный «стандарт», большинство компиляторов, предназначенных для машин с растущими вниз стеками, работали именно так, что приводило к более высокому уровню согласованности, чем существует сегодня.
Стандартного ABI не существует, потому что C всегда был ориентирован на максимальную производительность во время выполнения, а ABI с наивысшей производительностью зависит от базового оборудования. В результате ABI может использовать только стек или предпочесть регистры для передачи аргументов вызова функции и возвращаемых значений, если это необходимо для любого данного оборудования.
Например, даже amd64 (он же x86-64) имеет два соглашения о вызовах: Microsoft x64 и System V AMD64 ABI. Первый помещает 4 первых аргумента в регистры, а остальные в стек. Последний помещает 6 первых аргументов в регистры, а остальные в стек. Я понятия не имею, почему Microsoft создала несовместимое соглашение о вызовах для оборудования amd64. Насколько я знаю, вариант Microsoft имеет немного худшую производительность и был создан позже.
Для получения дополнительной информации см. https://en.wikipedia.org/wiki/X86_calling_conventions.
extern "C"во всем, что публикуете, и/или используете тот же компилятор для связанных исполняемых файлов. - person Steve Jessop schedule 20.12.2010