我试图了解ABI（比如System V）和C ++ Standard的区别。因此，C ++标准只是确定合法的C ++，以便编译器可以将其转换为适当的汇编代码。然后ABI规定此汇编代码如何与x86架构交互？这是两者之间更高层次的比较吗？
我的理由是对低延迟软件感兴趣我想知道阅读ABI会包含多少价值？
答案 0 :(得分：6)
标准根据您编写的代码定义程序应该执行的操作。 ABI定义了如何为特定平台实现，以便在不同运行中编译的代码（可能由不同的编译器/版本）进行交互。
也就是说，当你写：
void f(int i) { std::cout << i; }
标准定义了行为：对该函数的调用将导致参数值的打印输出。 ABI确定如何生成程序集以便可以调用函数（f的名称如何被修改？）参数可以传入（参数是否在堆栈中的某个位置？在寄存器中？）
关于问题的大胆部分......嗯，这取决于。 ABI是重读，很难阅读和理解它们。但是你应该至少熟悉一些基础知识，比如calling conventions（传递T类型对象的成本是多少？）......除此之外，我会将其作为一种被动的方法：如果您需要了解正在发生的事情，ABI可能会有所帮助。
大多数程序员不知道他们的平台的ABI，他们幸福地生活。我特别经常来回走了几次，以了解程序行为的一些特点。
答案 1 :(得分：5)
直接提问：了解ABI会在某种程度上对您有所帮助。但ABI不会告诉你特定C ++应用程序的效率如何 - 例如，使用内联的效果 - 这可能是有益的和有害的。类似地，使用vector与C风格数组的选择在某些情况下可能会带来好处，但在其他地方，它没有什么区别，因为它不值得从一个转换到另一个。
低延迟软件更多地是为了理解编译器在某些特定代码段中所做的事情，而不是确切地知道ABI中的段落13.6.2关于VTABLE如何组织的内容 - 除非当然，特定的你正在编译的代码直接受VTABLE布局的影响 - 大多数情况下它不是一个问题（除了理解虚函数是间接调用，它可能比相应的直接调用慢一点，并且对于简单的函数会明显慢于函数的内联版本。
你当然关心诸如“用于传递参数的寄存器数量”之类的事情，但是知道编译器是否使用R0，R1，R2或R13，R14和R15作为传递参数的三个寄存器是不太重要的。
最重要的是，无论你认为你理解编译器的作用有多少，查看汇编器输出，通过分析器运行代码等，都会比阅读ABI规范更多地告诉你。请记住，在典型代码中，90％的时间花在10％的代码上。修复使用总运行时间的0.001％的函数的“慢度”可能是浪费精力。