如果定义了标准的ABI,C/C++会失去什么?

在每个处理器上以最自然的方式实现事物的自由。

我认为,特别是C在比任何其他语言更不同的体系结构上有一致的实现。遵守目前通用、高端、通用的CPU优化的ABI,将需要对一些更古怪的机器进行非自然的扭曲。

除选择ABI的平台外,每个平台都具有向后兼容性。

C(或C++)语言规范定义了源语言。他们不关心运行它的处理器(一个C程序甚至可以被一个从系统解释,但这是不道德的,而且不划算的)。

根据定义,ABI与目标系统有关。它与处理器和系统(以及ABI后面的现有库)相关。

在过去,确实有一些处理器有专有的(即未公开的)规范(甚至它们的机器指令集也不是公共的),并且它们有一个非公共的ABI,随后是一个编译器(或多或少遵守语言标准)。

定义编程语言不需要与定义ABI相同的技能集。

^{你甚至可以为现有的处理器定义一个更新的ABI,但是这需要大量的工作(修补编译器,重新编译每一个东西,包括C&AM+C++标准库和你需要的所有实用程序和库),所以通常是无用的。}

而不是所有平台的通用ABI(这将是灾难性的,因为它只适合一个平台)。标准委员会可以说,每个平台都将符合特定的ABI。

但是:谁来定义它(第一个编译器通过门?)在这种情况下,他们获得了过度的竞争优势。或者是一个经过5年编纂的委员会(这是另一个可怕的想法)。

另外,它并没有给编译器提供进一步研究新的优化策略的机会,您将被困在定义标准时可用的技巧上。

在大多数平台上,执行速度会受到严重影响。如此之多以至于将C语言用于许多嵌入式平台可能不再合理。标准机构可能会对不同芯片制造商提起的与ABI不兼容的反垄断诉讼负责。

嗯,不会有一个标准的ABI,但大约有1000个。对于操作系统和处理器体系结构的每一个组合,您都需要一个。

最初,什么都不会丢失。但最终,有人会发现一些可怕的虫子,他们要么修复它,破坏ABI,要么离开它,造成问题。

我认为现在的情况很好。任何操作系统都可以自由地为自己定义一个ABI(它们确实如此),这是有意义的。操作系统的任务应该是定义它的ABI,而不是C/C++标准。

基本上,每个人都错过了一个C++ 14提案实际上定义了一个标准的ABI。它是一个标准的ABI,专门用于使用C++子集的图书馆。您定义“abi”代码的特定部分(如名称空间),并且需要符合子集。

不仅如此,它是由草药口吃,C++专家和作者的“例外C++”系列丛书。

这项提议涉及了便携式ABI困难的许多原因,以及新颖的解决方案。

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

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

注意,他将“目标平台”定义为CPU体系结构(x64、x86、ARM等)、操作系统和位(32/64)的组合。

因此,这里的目标是让C++代码(VisualStudio)能够在同一平台上与其他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年1月,我的手指仍然交叉。

C总是有一个标准的ABI,它甚至是用于任何最标准的ABI(我的意思是,当不同的语言或系统必须相互绑定时,C ABI是选择的ABI)。cABI是其他ABI中常见的一种ABI。C++虽然是扩展的,因此是基于C的,但实际上,C++的标准ABI更具挑战性,并且可能会给Ac++编译器自己的目标机器代码的实现带来问题。然而,它实际上似乎有一个标准的ABI;参见 Itanium C++ ABI .

所以问题可能不是太多,他们能释放什么?_157;,但更确切地说,它们松开了什么?_

边注: 需要牢记的是,ABI始终依赖于架构和操作系统。因此,如果标准abi__的意思是跨体系结构和平台的标准,那么可能从来没有或存在过这样的东西,但是通信协议。