Что может C/С++ "потерять", если они определяют стандартный ABI?

Ответ 1

Свобода реализовать вещи наиболее естественным образом на каждом процессоре.

Я предполагаю, что c, в частности, имеет соответствующие реализации на разных архитектурах, чем любой другой язык. Пребывание с помощью ABI, оптимизированного для обычных, высокопроизводительных CPU общего назначения, потребует неестественных искажений на некоторых более сложных машинах.

Ответ 2

Обратная совместимость на каждой платформе, кроме той, для которой выбрана ABI.

Ответ 3

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

ABI по определению представляет что-то о целевой системе. Это связано с процессором и системой (и с существующими библиотеками после ABI).

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

Определение языка программирования не требует того же набора навыков, что и определение ABI.

^{Вы даже можете определить новый ABI для существующего процессора, но для этого требуется много работы (исправление компилятора, перекомпиляция каждой вещи, включая стандартные библиотеки C и С++, и все необходимые вам утилиты и библиотеки), поэтому обычно бесполезен.}

Ответ 4

Вместо общего ABI для всех платформ (что было бы катастрофой, поскольку оно было бы оптимальным только для одной платформы). Стандартный комитет мог бы сказать, что каждая платформа будет соответствовать конкретному ABI.

Но: Кто его определяет (первый компилятор через дверь?). В этом случае они получают чрезмерное конкурентное преимущество. Или комитет после 5 лет компиляторов (что было бы еще одной ужасной идеей).

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

Ответ 5

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

Ответ 6

Ну, не было бы одного стандартного ABI, но около 1000. Вам понадобится один для каждой комбинации ОС и архитектуры процессора.

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

Я думаю, что сейчас ситуация в порядке. Любая ОС может свободно определять ABI для себя (и они это делают), что имеет смысл. Должна быть задача ОС определять ее ABI, а не стандарт C/С++.

Ответ 7

В принципе, все пропустили, что один из предложений С++ 14 действительно определил стандартный ABI. Это был стандартный ABI специально для библиотек, которые использовали подмножество С++. Вы определяете определенные разделы кода "ABI" (например, пространство имен) и должны соответствовать подмножеству.

Не только это, это было написано экспертом The Herb Stutter, С++ и автором книги "Исключительный С++".

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

https://isocpp.org/blog/2014/05/n4028

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf

Обратите внимание, что он определяет "целевую платформу" как комбинацию архитектуры процессора (x64, x86, ARM и т.д.), ОС и битности (32/64).

Таким образом, цель здесь - на самом деле иметь код С++ (Visual Studio), позволяющий разговаривать с другим кодом С++ (GCC, более ранняя Visual Studio и т.д.) на той же платформе. Это не цель универсального ABI, который позволяет библиотекам мобильных телефонов работать на вашей машине Windows.

Это предложение не было ратифицировано на С++ 14, однако оно было перенесено в фазу "Эволюция" на С++ 17 для дальнейшего обсуждения/итерации.

https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/c_14_is_ratified_the_view_from_the_june_2014_c_standard_meeting?lang=en

Итак, по состоянию на январь 2017 года мои пальцы остаются скрещенными.

Ответ 8

C всегда имел стандартный ABI, который даже тот, который используется для любого стандартного ABI (я имею в виду, что C ABI - это ABI выбора, когда разные языки или системы должны связываться друг с другом). C ABI является обычным ABI других ABI. С++ является более сложным, хотя расширение и, следовательно, основано на C, и, действительно, стандартный ABI для С++ является более сложным и может представлять проблемы для свободы, которую компилятор С++ имеет для собственной реализации целевого машинного кода. Однако, по-видимому, он имеет стандартный ABI; см. Itanium С++ ABI.

Таким образом, вопрос может быть не таким, "что они могут потерять?", а скорее "что они теряют?" (если когда-либо они действительно что-то теряют).

Примечание:, чтобы иметь в виду, что ABI всегда зависят от архитектуры и ОС. Поэтому, если "Стандартная ABI" означает "стандарт для архитектур и платформ", то, возможно, никогда не было или не было такой вещи, а протоколов связи.