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

Question

Название говорит обо всем.Я говорю конкретно о C / C ++, потому что оба рассматривают это как «проблему реализации».Я думаю, что определение стандартного интерфейса может облегчить построение модульной системы поверх него и многих других полезных вещей.
Что может «потерять» C / C ++, если они определят стандартный ABI?*

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

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

http://www.open -std.org / ОТК1 / SC22 / wg21 / документы / документы / 2014 / n4028.pdf

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

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

Это предложение НЕ было ратифицировано в C ++ 14, однако , оно было перемещено в фазу "Эволюции" C ++ 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 года мои пальцы остаются скрещенными.

Answer 7

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

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

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

Answer 8

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

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

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