标题说明了一切。我说的是 C/C++,因为两者都认为这是“实现问题”。我认为,定义标准接口可以简化在其之上构建模块系统以及许多其他好处。
如果他们定义了标准 ABI,C/C++ 会“失去”什么?
8 回答
在每个处理器上以最自然的方式实现事物的自由。
我想 c 特别是在比任何其他语言更多不同的架构上具有一致的实现。遵守为当前常见的高端通用 CPU 优化的 ABI 将需要在一些奇怪的机器上进行不自然的扭曲。
除了选择 ABI 的平台外,每个平台都具有向后兼容性。
基本上,每个人都错过了 C++14 提案之一实际上确实定义了标准 ABI。它是一个标准 ABI,专门用于使用 C++ 子集的库。您定义“ABI”代码的特定部分(如命名空间),并且需要符合子集。
不仅如此,它还由 C++ 专家和“Exceptional C++”系列丛书的作者 THE Herb Stutter 编写。
该提案涉及便携式 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++ 代码(Visual Studio)能够与同一平台上的其他 C++ 代码(GCC、旧版 Visual Studio 等)进行通信。这不是让手机库在您的 Windows 机器上运行的通用 ABI 的目标。
这个提议在 C++14 中没有被批准,但是,它被移到了 C++17 的“进化”阶段以供进一步讨论/迭代。
所以截至 2017 年 1 月,我的手指仍然交叉。
而不是适用于所有平台的通用 ABI(这将是灾难性的,因为它只对一个平台是最佳的)。该标准的委员会可以说每个平台都将符合特定的 ABI。
但是:谁定义了它(第一个通过门的编译器?)。在这种情况下,他们获得了过度的竞争优势。或者经过 5 年的编译器委员会(这将是另一个可怕的想法)。
此外,它并没有给编译器留出对新优化策略进行进一步研究的余地,您将被定义标准时可用的技巧所困。
C(或 C++)语言规范定义了源语言。他们不关心运行它的处理器(AC 程序甚至可以由人类奴隶解释,但这是不道德的,也不划算)。
根据定义,ABI 是关于目标系统的东西。它与处理器和系统(以及 ABI 之后的现有库)有关。
过去,确实发生过某些处理器具有专有(即未公开)规范(甚至它们的机器指令集不公开),并且它们具有非公开 ABI,然后是编译器(或多或少尊重语言标准) )。
定义编程语言不需要与定义 ABI 相同的技能集。
您甚至可以为现有处理器定义更新的 ABI,但这需要大量工作(修补编译器、重新编译所有内容,包括 C 和 C++ 标准库以及您需要的所有实用程序和库),因此通常是无用的。
大多数平台上的执行速度都会受到严重影响。如此之多,以至于将 C 语言用于许多嵌入式平台可能不再合理。该标准机构可能会对与 ABI 不兼容的各种芯片制造商提起的反垄断诉讼负责。
好吧,不会有一个标准 ABI,而是大约 1000 个。对于操作系统和处理器架构的每种组合,您都需要一个。
最初,什么都不会丢失。但最终,有人会发现一些可怕的错误,他们要么修复它,破坏 ABI,要么留下它,导致问题。
我认为现在的情况很好。任何操作系统都可以自由地为自己定义 ABI(他们确实这样做了),这是有道理的。定义其 ABI 应该是操作系统的工作,而不是 C/C++ 标准。
C 总是有一个标准 ABI,甚至是用于任何最标准 ABI 的那个(我的意思是,当不同的语言或系统必须相互绑定时,C ABI 是首选的 ABI)。C ABI 是其他 ABI 的一种常见 ABI。尽管 C++ 扩展并因此基于 C,但 C++ 更复杂,而且确实,C++ 的标准 ABI 更具挑战性,并且可能会给 C++ 编译器自己实现目标机器代码的自由度带来问题。但是,它似乎实际上有一个标准的 ABI;请参阅安腾 C++ ABI。
所以问题可能不是“他们能释放什么?”,而是“他们能释放什么?” (如果他们真的失去了一些东西)。
旁注: 需要记住 ABI 始终依赖于架构和操作系统。因此,如果“标准 ABI”的意思是“跨架构和平台的标准”,那么可能永远不会有这样的东西,而是通信协议。