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