我对所有这些低级的东西，汇编语言都比较陌生。并且想了解更多细节。为什么 Linux、Windows 汇编语言之间存在差异？
据我了解，当我编译 C 代码时，操作系统并不会真正产生纯机器或汇编代码，它会产生依赖于操作系统的二进制代码。但为什么呢？
例如，当我使用 x86 系统时，CPU 只理解 x86 ASM 对吗？那么为什么我们不编写纯 x86 汇编代码，为什么根据操作系统会有不同的汇编变体？如果我们编写纯 ASM 或 OS 产生纯 ASM，那么操作系统之间是否不会出现二进制兼容性问题？
我真的很想知道它们背后的所有原因。任何详细的答案、文章、书籍都会很棒。谢谢。
【问题讨论】：
标签： assembly operating-system x86
没有区别。如果处理器相同，则汇编代码相同。在 Windows 上编译的 x86 代码与 Linux 上的 x86 代码二进制兼容。编译器不会生成依赖于操作系统的二进制代码，但它可以将代码打包成不同的格式（例如 PE 与 ELF）。
区别在于使用的库。为了使用操作系统的东西（例如 I/O），您必须链接到操作系统的库。不出所料，Windows 系统库在 Linux 机器上不可用（当然，除非你有 Wine），反之亦然。
【讨论】：
好吧，你不直接运行汇编。代码必须是某种可执行格式：windows 使用 PE，现在大多数 Unices 使用 ELF（尽管还有其他的，比如 a.out）。
基本的汇编指令是一样的，你用它们创建的函数也是一样的。
问题在于访问其他资源。处理器确实很擅长计算，但不能访问硬盘，不能在屏幕上打印字符，不能连接蓝牙手机。这些元素总是以某种方式依赖于操作系统。它们是根据系统调用实现的，其中处理器向操作系统发出信号以执行特定任务。 Linux 上的任务编号 17 不一定是 Windows 上的任务 17；他们甚至可能没有等价物。
由于大多数库在其最低级别都有一些系统调用，这就是为什么不能在每种情况下都重新编译代码的原因。
【讨论】：
除了其他答案。
操作系统规定其Application Binary Interface (ABI)，其中包括可执行对象的格式。这些是用于 Linux（和许多其他类 Unix 系统）的 Executable and Linkable Format (ELF) 和用于 Windows 的 Portable Executable (PE)。其他格式见this table。
【讨论】：
除非您使用的是嵌入式系统开发环境，否则您正在使用针对特定运行时的编译器进行编译。该运行时定义了使用硬件的约定：参数传递、异常处理等。这些约定与操作系统交互，或至少与程序需要链接的可用运行时库交互.
【讨论】：
从历史上看，Linux 汇编倾向于使用 AT&T 语法来完成，因为这是 GNU Assembler 支持的。同样，Windows 汇编器倾向于使用 Intel 语法，如 MASM 和 NASM。
所有 x86 汇编器都产生相同的输出——即 x86 机器代码。你可以在 Linux 上使用 NASM 或 GNU Assembler 在 Intel 语法下编程，在 Windows 上使用 GNU Assembler 在 AT&T 语法下编程。
【讨论】：
Assembly 语言与 CPU 架构相关的不是操作系统，而是操作系统。有一系列编译成二进制的系统函数，你的汇编程序可以通过中断调用来调用它们。比如标准输入输出，操作ecc....
【讨论】：
操作系统决定了两件事：(1) calling convention，它定义了参数如何进入堆栈并因此影响汇编代码，以及 (2) 实现内存分配、输入等常见功能的运行时库/output，高级数学等。
因此，虽然x+y 在 x86 处理器上的 Windows 或 Linux 下编译为相同的汇编代码，但由于调用约定和数学库不同，y = sin(x) 会有所不同。
除此之外，汇编语言本身还依赖于处理器。 x86、x86_64、ARM、PowerPC，都有自己的汇编语言。
【讨论】：
只要我们坚持使用 x86，汇编语言就没有区别（尽管汇编程序之间可能存在差异，因此使用的符号也会有所不同）。 Linux 和 Microsoft Windows 都可以在其他架构上运行，在 Linux 上更是如此。
但是，当今的操作系统不仅仅将程序加载到内存中然后放手。它提供了大量的服务。由于它还相互保护程序，因此它施加了限制。要进行基本计算以外的任何操作，通常需要通过操作系统。 （对于旧操作系统，如 MS-DOS 和 CP/M 来说，情况就不那么正确了，它们可以加载独立运行的程序，但现在几乎每个非嵌入式系统都有现代操作系统。）
程序也不存储为纯二进制 blob。通常需要与其他库链接，通常是在加载程序以执行时（例如，DLL 的工作方式），并且需要与操作系统链接。操作系统可能需要其他信息，因此必须有一些关于可执行文件中二进制 blob 的信息。这因操作系统而异。
因此，可执行文件必须采用某种格式才能加载到内存中，这因操作系统而异。为了做任何有用的事情，他们必须进行操作系统调用，这在系统之间是不同的。这就是为什么您不能获取 Windows 可执行文件和相关库并在 Linux 上运行它的原因。
【讨论】：
存在一些适用于各种平台的汇编程序，给定一个源文件，它们将直接生成一个输出二进制文件，该文件被设计为加载到特定地址。这种汇编器在一些小型微控制器或一些历史悠久的处理器（如 6502 和 Z80）中很受欢迎。组装程序时，有必要知道它预期驻留的地址；使用不同的地址将需要重新组装程序。另一方面，在这样的系统中组装是一个单步过程。在源代码上运行汇编程序并获得可执行输出。在某些情况下，可以一次将源代码、汇编程序和输出全部保存在内存中（在我的 Commodore 64 上，我使用了一个汇编程序，它发表在 Compute 的 Gazette 杂志上，就是这样工作的）。
尽管在地址更改时重新组装所有内容对于“接管机器”的程序来说可能是可行的，但在许多情况下，最好使用多步骤过程，将源文件处理为目标代码文件，其中包含汇编指令，但也包含关于它们的各种“符号”信息；然后以各种方式处理这些文件，以便生成可以直接加载到内存中的内存映像，或者生成一个组合的可重定位目标文件，操作系统的加载程序将知道如何调整它可能加载到的任何地址.
为了使对象链接系统有用，它必须允许延迟某些类型的地址计算，直到程序被链接或加载。一些系统只允许在链接/加载时执行极其简单的计算，而其他系统则允许更复杂的计算。更简单的方案在可行时可能更有效，但它们的局限性可能会迫使解决方法。例如，将使用 BX 循环通过小于 256 字节的数据结构的例程可能会编写为：
mov bx,StartAddr
lp: 移动，[bx] ...做一些计算 公司 cmp bl,
可以使用cmp bx,(StartAddr+Length)，但是如果编译工具可以支持的话，只比较低字节会更快。另一方面，某些类型的 16 位汇编/链接工具可能要求所有地址修复都使用存储在代码中的 16 位地址。
由于不同的系统允许其目标代码格式具有不同的特性，因此它们需要其汇编语言中的不同特性来控制它们。指令集可能由芯片制造商指定，但表达可重定位地址计算的特性一般不指定。
【讨论】：