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