应用程序二进制接口(ABI)

功能:

从程序员的模型到底层系统的域数据的转换 类型，大小，对齐，调用约定，它控制如何 函数的参数被传递并返回检索到的值;的 系统调用编号以及应用程序应该如何进行系统调用 到操作系统;高级语言编译器的名称 破坏方案、异常传播和调用约定 在同一平台上的编译器之间，但不需要 跨平台兼容性……

现有的实体:

直接参与程序执行的逻辑块:ALU， 通用寄存器，用于内存/ I/O映射的寄存器，等等…

消费者:

语言处理器，链接器，汇编器…

任何必须确保构建工具链作为一个整体工作的人都需要这些。如果你用汇编语言写一个模块，用Python写另一个模块，而不是你自己的引导加载程序想要使用操作系统，那么你的“应用程序”模块是跨“二进制”边界工作的，需要这种“接口”的协议。

c++命名混乱，因为应用程序中可能需要链接来自不同高级语言的目标文件。考虑使用GCC标准库对Visual c++构建的Windows进行系统调用。

ELF是用于解释的来自对象文件的链接器的一种可能期望，尽管JVM可能有其他想法。

对于一个Windows RT商店应用程序，如果你真的想让一些构建工具链一起工作，尝试搜索ARM ABI。

让我至少回答你问题的一部分。通过一个例子说明Linux ABI如何影响系统调用，以及它为什么有用。

A systemcall is a way for a userspace program to ask the kernelspace for something. It works by putting the numeric code for the call and the argument in a certain register and triggering an interrupt. Than a switch occurs to kernelspace and the kernel looks up the numeric code and the argument, handles the request, puts the result back into a register and triggers a switch back to userspace. This is needed for example when the application wants to allocate memory or open a file (syscalls "brk" and "open").

现在系统调用有简短的名称“brk”等和相应的操作码，这些在系统特定的头文件中定义。只要这些操作码保持不变，您就可以使用不同更新的内核运行相同的已编译用户域程序，而无需重新编译。这样就有了预编译二进制文件使用的接口，因此就有了ABI。

应用程序二进制接口(ABI)

功能:

从程序员的模型到底层系统的域数据的转换 类型，大小，对齐，调用约定，它控制如何 函数的参数被传递并返回检索到的值;的 系统调用编号以及应用程序应该如何进行系统调用 到操作系统;高级语言编译器的名称 破坏方案、异常传播和调用约定 在同一平台上的编译器之间，但不需要 跨平台兼容性……

现有的实体:

直接参与程序执行的逻辑块:ALU， 通用寄存器，用于内存/ I/O映射的寄存器，等等…

消费者:

语言处理器，链接器，汇编器…

任何必须确保构建工具链作为一个整体工作的人都需要这些。如果你用汇编语言写一个模块，用Python写另一个模块，而不是你自己的引导加载程序想要使用操作系统，那么你的“应用程序”模块是跨“二进制”边界工作的，需要这种“接口”的协议。

c++命名混乱，因为应用程序中可能需要链接来自不同高级语言的目标文件。考虑使用GCC标准库对Visual c++构建的Windows进行系统调用。

ELF是用于解释的来自对象文件的链接器的一种可能期望，尽管JVM可能有其他想法。

对于一个Windows RT商店应用程序，如果你真的想让一些构建工具链一起工作，尝试搜索ARM ABI。

为了调用共享库中的代码，或者在编译单元之间调用代码，object文件需要包含调用的标签。c++修改了方法标签的名称，以加强数据隐藏并允许重载方法。这就是为什么您不能混合来自不同c++编译器的文件，除非它们显式地支持相同的ABI。

实际上你根本不需要ABI如果

你的程序没有函数，而且—— 你的程序是一个单独运行的可执行文件(即一个嵌入式系统)，它实际上是唯一在运行的东西，它不需要与其他任何东西对话。

过度简化的总结:

API:“这里是你可以调用的所有函数。” ABI:“这是调用函数的方法。”

ABI是编译器和链接器遵守的一组规则，以便编译您的程序，使其正常工作。ABIs涵盖多个主题:

Arguably the biggest and most important part of an ABI is the procedure call standard sometimes known as the "calling convention". Calling conventions standardize how "functions" are translated to assembly code. ABIs also dictate the how the names of exposed functions in libraries should be represented so that other code can call those libraries and know what arguments should be passed. This is called "name mangling". ABIs also dictate what type of data types can be used, how they must be aligned, and other low-level details.

更深入地了解调用约定，我认为它是ABI的核心:

机器本身没有“功能”的概念。当你用高级语言(如c)编写函数时，编译器会生成一行汇编代码，如_MyFunction1:。这是一个标签，它最终将被汇编程序解析为一个地址。这个标签标记了程序集代码中“函数”的“开始”。在高级代码中，当你“调用”这个函数时，你真正做的是导致CPU跳转到那个标签的地址并继续在那里执行。

在为跳转做准备时，编译器必须做一些重要的事情。调用约定就像一个清单，编译器遵循它来完成所有这些事情:

First, the compiler inserts a little bit of assembly code to save the current address, so that when your "function" is done, the CPU can jump back to the right place and continue executing. Next, the compiler generates assembly code to pass the arguments. Some calling conventions dictate that arguments should be put on the stack (in a particular order of course). Other conventions dictate that the arguments should be put in particular registers (depending on their data types of course). Still other conventions dictate that a specific combination of stack and registers should be used. Of course, if there was anything important in those registers before, those values are now overwritten and lost forever, so some calling conventions may dictate that the compiler should save some of those registers prior to putting the arguments in them. Now the compiler inserts a jump instruction telling the CPU to go to that label it made previously (_MyFunction1:). At this point, you can consider the CPU to be "in" your "function". At the end of the function, the compiler puts some assembly code that will make the CPU write the return value in the correct place. The calling convention will dictate whether the return value should be put into a particular register (depending on its type), or on the stack. Now it's time for clean-up. The calling convention will dictate where the compiler places the cleanup assembly code. Some conventions say that the caller must clean up the stack. This means that after the "function" is done and the CPU jumps back to where it was before, the very next code to be executed should be some very specific cleanup code. Other conventions say that the some particular parts of the cleanup code should be at the end of the "function" before the jump back.

有许多不同的abi /调用约定。主要有:

x86或x86-64 CPU(32位环境): CDECL STDCALL FASTCALL VECTORCALL THISCALL x86-64(64位环境): SYSTEMV MSNATIVE VECTORCALL ARM CPU(32位) AAPCS ARM处理器(64位) AAPCS64

这里有一个很棒的页面，它实际显示了为不同的abi编译时生成的程序集的差异。

另一件需要提及的事情是，ABI不仅仅与程序的可执行模块内部相关。链接器还使用它来确保程序正确调用库函数。您的计算机上运行着多个共享库，只要编译器知道它们各自使用的ABI，它就可以正确地从它们调用函数，而不会破坏堆栈。

编译器理解如何调用库函数是非常重要的。在一个托管平台上(也就是说，一个OS加载程序的平台)，如果不调用内核，您的程序甚至不能闪烁。

应用程序二进制接口(ABI)类似于API，但是调用者不能在源代码级别上访问该函数。只有二进制表示是可访问的/可用的。

abi可以在处理器体系结构级别或操作系统级别定义。 abi是编译器的代码生成器阶段要遵循的标准。该标准由操作系统或处理器决定。

功能:定义机制/标准，使函数调用独立于实现语言或特定的编译器/链接器/工具链。提供允许JNI或Python-C接口等的机制。

现有实体:机器代码形式的函数。

消费者:另一个函数(包括用另一种语言编写的、由另一种编译器编译或由另一种链接器链接的函数)。