2.1.1. 汇编的优点

汇编可以表达非常底层的细节

• 您可以访问机器相关的寄存器和 I/O

• 您可以控制关键代码段的确切代码行为，否则这些代码段可能会涉及多个软件线程或硬件设备之间的死锁

• 您可以打破常用编译器的约定，这可能会允许进行一些优化（例如，暂时打破关于内存分配、线程、调用约定等的规则）

• 您可以构建使用不兼容约定的代码片段之间的接口（例如，由不同的编译器生成，或由低级接口分隔）

• 您可以访问处理器的不寻常编程模式（例如，16 位模式，用于连接启动代码、固件或 Intel PC 上的旧代码）

• 您可以为紧密循环生成相当快的代码，以应对糟糕的非优化编译器（但是，有免费的优化编译器可用！）

• 您可以生成针对特定硬件设置完美调整的手工优化代码，但不适用于其他人的硬件设置

• 您可以为新语言的优化编译器编写一些代码（这是极少数人会做的事情，即使是他们也不常做）

• 即，您可以完全控制您的代码

2.1.2. 汇编的缺点

汇编是一种非常低级的语言（比手工编码二进制指令模式还要高一级）。这意味着

• 最初编写起来既冗长又乏味

• 非常容易出错

• 您的错误可能很难追踪

• 您的代码可能相当难以理解和修改，即难以维护

• 结果是不可移植到其他架构，无论是现有的还是即将出现的

• 您的代码将仅针对同一架构的特定实现进行优化：例如，在 Intel 兼容平台中，每个 CPU 设计及其变体（处理单元、缓存、RAM、总线、磁盘的相对延迟、吞吐量和容量，FPU、MMX、3DNOW、SIMD 扩展等的存在）都意味着潜在的完全不同的优化技术。CPU 设计已经包括：Intel 386、486、奔腾、PPro、PII、PIII、PIV；Cyrix 5x86、6x86、M2；AMD K5、K6 (K6-2、K6-III)、K7 (Athlon、Duron)。新的设计不断涌现，所以不要指望此列表和您的代码是最新的。

• 您花费更多时间在一些细节上，而无法专注于已知能带来最大加速的小型和大型算法设计（例如，您可能会花费一些时间在汇编中构建非常快速的列表/数组操作原语；只有哈希表才能更快地加速您的程序；或者，在另一种情况下，是二叉树；或者一些分布在 CPU 集群上的高级结构）

• 算法设计中的一个小变化可能会完全使您现有的所有汇编代码失效。因此，要么您已准备好（并且能够）重写所有代码，要么您被束缚于特定的算法设计

• 在与标准基准测试相差不远的代码上，商业优化编译器胜过手工编码的汇编（嗯，这在 x86 架构上不如在 RISC 架构上那么真实，对于广泛可用/免费的编译器来说可能不太真实；无论如何，对于典型的 C 代码，GCC 相当不错）；

• 而且在任何情况下，正如版主 John Levine 在 comp.compilers 上所说，

  
  "编译器 使得 使用 复杂 数据 结构 容易得多，
  并且 编译器 不会 在 半途 感到 厌烦
  并且 生成 可靠地 相当 不错的 代码。"
  

  它们还将在整个（庞大的）程序中正确地传播代码转换，并在过程和模块边界之间优化代码。

2.1.3. 评估

总而言之，您可能会发现，尽管有时需要使用汇编，甚至在少数情况下可能有用，但您仍然希望

• 尽量减少汇编代码的使用

• 将此代码封装在明确定义的接口中

• 让您的汇编代码从以高于汇编的更高级语言表达的模式自动生成（例如，GCC 内联汇编宏）

• 拥有自动工具将这些程序翻译成汇编代码

• 如果可能，使此代码得到优化

• 以上所有内容，即编写（一个扩展到）优化编译器后端。

即使在需要汇编时（例如，OS 开发），您也会发现不需要太多汇编，并且上述原则仍然适用。

请参阅 Linux 内核源代码：尽可能少地使用汇编，从而产生快速、可靠、可移植、可维护的操作系统。即使像 DOOM 这样成功的游戏也几乎完全是用 C 语言编写的，只有一小部分是用汇编语言编写的，以提高速度。

2.2.1. 实现高效代码的通用过程

正如 Charles Fiterman 在 comp.compilers 上关于人类与计算机生成的汇编代码所说

人类 应该 总是 获胜， 原因 如下。

首先， 人类 用 高级 语言 编写 整个 东西。
其次， 他 对其 进行 性能分析， 以 找到 花费 时间 的 热点 区域。
第三， 他 让 编译器 为 这些 小 代码 段 生成 汇编代码。
第四， 他 手工 调整 它们， 寻找 机器 生成 代码 的 微小 改进。
生成的 代码。

人类 获胜 是因为 他 可以 使用 机器。

2.2.2. 具有优化编译器的语言

ObjectiveCAML、SML、CommonLISP、Scheme、ADA、Pascal、C、C++ 等语言都具有免费的优化编译器，它们将优化您程序的大部分，并且通常比手工编码的汇编代码（即使是对于紧密循环）做得更好，同时允许您专注于更高级别的细节，并且不妨碍您以上述方式获得额外几个百分点的性能，一旦您达到了稳定的设计。当然，大多数这些语言也有商业优化编译器！

一些语言的编译器生成 C 代码，C 代码可以由 C 编译器进一步优化：LISP、Scheme、Perl 和许多其他语言。速度相当不错。

2.2.3. 加速代码的通用过程

至于加速代码，您应该仅对性能分析工具始终如一地确定为性能瓶颈的程序部分执行此操作。

因此，如果您确定某个代码部分太慢，则应

• 首先尝试使用更好的算法；

• 然后尝试编译它而不是解释它；

• 然后尝试启用和调整编译器的优化；

• 然后给编译器关于如何优化的提示（LISP 中的类型信息；GCC 的寄存器使用；大多数编译器中的许多选项等）。

• 然后可能退回到汇编编程

最后，在您最终编写汇编代码之前，您应该检查生成的代码，以检查问题是否真的是代码生成不良，因为情况可能并非如此：编译器生成的代码可能比您编写的代码更好，尤其是在现代多流水线架构上！程序中速度慢的部分可能本质上就是如此。现代架构上使用快速处理器的最大问题是由于内存访问、缓存未命中、TLB 未命中和页面错误造成的延迟；寄存器优化变得毫无用处，您将更有利地重新思考数据结构和线程，以实现更好的内存访问局部性。也许完全不同的问题处理方法可能会有所帮助。

2.2.4. 检查编译器生成的代码

有很多理由检查编译器生成的汇编代码。以下是您将如何处理此类代码

• 检查是否可以通过手工编码的汇编（或通过调整编译器开关）明显地增强生成的代码

• 如果是这种情况，请从生成的代码开始修改，而不是从头开始

• 更一般地说，使用生成的代码作为存根进行修改，这至少可以正确地了解您的汇编例程与外部世界交互的方式

• 跟踪编译器中的错误（希望这种情况更少见）

生成汇编代码的标准方法是以-S标志调用您的编译器。这适用于大多数 Unix 编译器，包括 GNU C 编译器 (GCC)，但 YMMV。至于 GCC，它将使用-fverbose-asm命令行选项生成更易于理解的汇编代码。当然，如果您想获得良好的汇编代码，请不要忘记您常用的优化选项和提示！

3.1.1. 在哪里找到 GCC

GCC 主页是 http://gcc.gnu.org。

GCC 的 DOS 端口称为 DJGPP。

存在两个 Win32 GCC 端口：cygwin 和 mingw

还有一个名为 EMX 的 GCC OS/2 端口；它也可以在 DOS 下工作，并包含许多 unix 模拟库例程。请访问以下站点了解更多信息：ftp://ftp.leo.org/pub/comp/os/os2/leo/gnu/emx+gcc/。

3.1.2. 在哪里找到 GCC 内联汇编的文档

GCC 的文档包括 TeXinfo 格式的文档文件。您可以使用 TeX 编译它们并打印结果，或者将它们转换为.info格式，然后使用 emacs 浏览它们，或者将它们转换为.html格式，或者几乎任何您喜欢的格式；使用正确的工具转换为您喜欢的任何格式，或者直接阅读。这些.info文件通常可以在任何良好的 GCC 安装中找到。

要查找的正确部分是C 扩展::扩展汇编:

章节调用 GCC::子模型选项::i386 选项:也可能会有所帮助。特别是，它给出了寄存器的 i386 特定约束名称abcdSDB对应于%eax, %ebx, %ecx, %edx, %esi, %edi和%ebp分别 (没有字母对应于%esp).

DJGPP 游戏资源（不仅适用于游戏黑客）曾经有一个专门关于汇编的页面，但它已关闭。它的数据已在 DJGPP 站点上恢复，该站点包含大量其他有用的信息：http://www.delorie.com/djgpp/doc/brennan/。

GCC 依赖于 GAS 进行汇编，并遵循其语法（见下文）；请注意，内联汇编需要引用百分号字符，它们将被传递给 GAS。请参阅下面关于 GAS 的章节。

在linux/include/asm-i386/Linux 内核源代码的子目录中找到大量有用的示例。

3.1.3. 调用 GCC 构建正确的内联汇编代码

由于内核头文件中的汇编例程（以及您自己的头文件，如果您尝试使您的汇编程序设计像 Linux 内核中那样干净）嵌入在extern inline函数中，GCC 必须使用-O标志（或-O2, -O3等）来调用，这些例程才能可用。否则，您的代码可能可以编译，但无法正确链接，因为它将查找未内联的extern库中与您的程序链接的函数！另一种方法是链接到包含例程回退版本的库。

可以使用-fno-asm禁用内联汇编，这将导致编译器在使用扩展内联汇编语法时终止，否则生成对名为asm()的外部函数的调用，链接器无法解析该函数。为了对抗这样的标志，-fasm恢复对asm关键字的处理。

更一般地，x86 平台上 GCC 的良好编译标志是

gcc -O2 -fomit-frame-pointer -W -Wall

-O2在大多数情况下是良好的优化级别。除了它之外的优化需要更多时间，并产生更大的代码，但速度只快一点点；这种过度优化可能只对紧凑循环（如果有的话）有用，您可能无论如何在汇编中执行这些循环。在您需要对少数文件进行真正强大的编译器优化的情况下，请考虑使用高达-O6.

-fomit-frame-pointer允许生成的代码跳过愚蠢的帧指针维护，这使得代码更小更快，并释放一个寄存器用于进一步优化。它排除了轻松使用调试工具 (gdb) 的可能性，但是当您使用这些工具时，您根本不再关心大小和速度了。

-W -Wall启用所有有用的警告，并帮助您捕获明显的愚蠢错误。

您可以添加一些 CPU 特定的-m486或类似的标志，以便 GCC 将生成更适合您的精确 CPU 的代码。请注意，现代 GCC 具有-mpentium和类似的标志（PGCC 甚至更多），而 GCC 2.7.x 和更旧的版本则没有。Linux 内核中应该有一个好的 CPU 特定标志选择。查看您当前 GCC 安装的 TeXinfo 文档以获取更多信息。

-m386将有助于优化大小，因此也有助于在内存紧张和/或负载重的计算机上提高速度，因为大型程序会导致交换，这比大型代码带来的任何“优化”都更抵消效果。在这种设置中，停止使用 C，而是使用一种有利于代码分解的语言，例如函数式语言和/或 FORTH，并使用基于字节码或字码的实现可能是有用的。

请注意，您可以逐文件更改代码生成标志，因此性能关键型文件将使用最大优化，而其他文件将针对大小进行优化。

为了进一步优化，选项-mregparm=2和/或相应的函数属性可能会有所帮助，但在链接到外部代码（包括 libc）时可能会带来很多问题。有一些方法可以正确声明外部函数，以便生成正确的调用序列，或者您可能希望重新编译外部库以使用相同的基于寄存器的调用约定...

请注意，您可以通过编辑文件/usr/lib/gcc-lib/i486-linux/2.7.2.3/specs或系统上的任何位置来使这些标志成为默认值（最好不要添加-W -Wall在那里，虽然）。可以通过 gcc -v 找到系统上 GCC specs 文件的确切位置。

3.1.4. 宏支持

GCC 允许（并要求）您在内联汇编代码中指定寄存器约束，以便优化器始终了解它；因此，内联汇编代码实际上是由模式组成的，而不是强制性的精确代码。

因此，您可以将汇编放入 CPP 宏和内联 C 函数中，以便任何人都可以在任何 C 函数/宏中使用它。内联函数非常类似于宏，但有时使用起来更简洁。请注意，在所有这些情况下，代码都会被复制，因此只有局部标签（样式为1:样式）才应在该汇编代码中定义。但是，宏允许将非局部定义的标签名称作为参数传递（否则，您应该使用额外的元编程方法）。另请注意，传播内联汇编代码会传播其中潜在的错误；因此，请双倍注意此类内联汇编代码中的寄存器约束。

最后，C 语言本身可以被认为是汇编程序设计的一个很好的抽象，它可以减轻您组装的大部分麻烦。

3.2.1. 在哪里找到它

在您找到 GCC 的同一个位置，在 binutils 包中找到它。最新版本的 binutils 可从 http://sources.redhat.com/binutils/ 获取。

3.2.2. 什么是 AT&T 语法

因为 GAS 是为支持 32 位 unix 编译器而发明的，所以它使用标准的 AT&T 语法，该语法与标准 m68k 汇编器的语法非常相似，并且在 UNIX 世界中是标准的。这种语法既不比 Intel 语法差，也不比它好。它只是不同。当您习惯它时，您会发现它比 Intel 语法更有规律，尽管有点枯燥。

以下是关于 GAS 语法的主要注意事项

• 寄存器名称以%%%eax, 为前缀，因此寄存器是%dl等等，而不是仅仅是, eaxdl

• 等等。这使得可以将外部 C 符号直接包含在汇编源代码中，而不会有任何混淆的风险，也不需要丑陋的下划线前缀。操作数的顺序是源操作数在前，目标操作数在后，这与 Intel 约定目标操作数在前，源操作数在后相反。因此，在 Intel 语法中是mov eax,edx（将寄存器edx等等，而不是仅仅是的内容移动到寄存器）在 GAS 语法中将是.

• mov %edx,%eax操作数大小作为指令名称的后缀指定。后缀是b表示 (8 位) 字节，w表示 (16 位) 字，以及l表示 (32 位) 长字。例如，上述指令的正确语法应该是movl %edx,%eax

• 。但是，gas 不需要严格的 AT&T 语法，因此当可以从寄存器操作数中猜测大小，否则默认为 32 位（带有警告）时，后缀是可选的。$立即操作数用$前缀标记，如%eax).

• addl $5,%eax（将立即长字值 5 添加到寄存器缺少操作数前缀表示它是内存内容；因此movl $foo,%eaxedx%eax将变量foo的地址放入 %eax，但movl $foo,%eaxedx%eax.

• movl foo,%eax将变量索引或间接寻址是通过将索引寄存器或间接内存单元地址括在括号中来完成的，如%ebp).

testb $0x80,17(%ebp)

（测试从单元格指向的偏移量 17 处的字节值的高位.info 注意：有一些程序可以帮助您在 AT&T 和 Intel 汇编程序语法之间转换源代码；其中一些能够执行双向转换。GAS 在 TeXinfo 格式中具有全面的文档，至少与源代码发行版一起提供。使用 Emacs 或其他工具浏览提取的

页面。GAS 源代码包中曾经有一个名为 gas.doc 或 as.doc 的文件，但它已合并到 TeXinfo 文档中。当然，如有疑问，最终文档是源代码本身！您特别感兴趣的部分是机器依赖性::i386-依赖性:同样，Linux（OS 内核）的源代码提供了很好的示例；请参阅linux/arch/i386/, 以下文件, kernel/*.S.

boot/compressed/*.S

math-emu/*.S

如果您正在编写一种语言、一个线程包等，您不妨看看其他语言（OCaml、Gforth 等）或线程包（QuickThreads、MIT pthreads、LinuxThreads 等）或其他任何东西是如何做的。

最后，只需将 C 程序编译为汇编代码就可以向您展示您想要的指令类型的语法。请参阅上面的章节。3.2.3. Intel 语法好消息是从 binutils 2.10 版本开始，GAS 也支持 Intel 语法。可以使用

.intel_syntax

指令触发它。不幸的是，此模式在官方 binutils 手册中（尚未？）记录，因此如果您想使用它，请尝试查看 http://www.lxhp.in-berlin.de/lhpas86.html，这是从 AMD 64 位端口的 binutils 2.11 中提取的。3.2.4. 16 位模式和Binutils (2.9.1.0.25+) 现在完全支持 i386 PC 上的 16 位模式（寄存器和寻址）。使用.code16

.code32在汇编模式之间切换。此外，包括 oskit 作者在内的几个人使用的一个巧妙技巧是强制 GCC 为 16 位实模式生成代码，使用内联汇编语句

asm(".code16\n")

。GCC 仍将仅发出 32 位寻址模式，但 GAS 将为它们插入适当的 32 位前缀。3.2.5. 宏支持GAS 包含一些宏功能，如 texinfo 文档中详细介绍的那样。此外，虽然 GCC 将.s文件识别为发送到 GAS 的原始汇编代码，但它也将

.S

3.3. NASM

Netwide Assembler 项目提供了一个很棒的 i386 汇编器，用 C 编写，它应该足够模块化，最终支持所有已知的语法和对象格式。

3.3.1. 在哪里找到 NASMhttp://www.nasm.us, http://sourceforge.net/projects/nasm/在您常用的 metalab 镜像中的devel/lang/asm/目录中的二进制版本。也应该可以作为.rpm或

.deb

在您常用的 Linux 发行版中获得。

3.3.2. 它的作用语法是 Intel 风格。集成了全面的宏处理支持。, 支持的对象文件格式有, bin, aout, coff, elfas86obj, (DOS),win32

rdf

（它们自己的格式）。

NASM 可以用作免费 LCC 编译器的后端（包含支持文件）。

除非您将 BCC 用作 16 位编译器（这超出了本 32 位 HOWTO 的范围），否则您绝对应该使用 NASM 而不是 AS86 或 MASM，因为它可以在所有平台上运行。

NASM 附带一个反汇编器 NDISASM。

还有其他汇编器具有各种有趣和突出的功能，您可能也会对它们感兴趣。

它们可能处于不同的开发阶段，并且可能是非经典的/高级的/或其他任何类型。

3.4.1. AS86

AS86 是一个 80x86 汇编器（16 位和 32 位），具有集成的宏支持。它主要使用 Intel 语法，尽管在寻址模式方面略有不同。在一段时间之前，它曾在多个项目中使用，包括 Linux 内核，但最终这些项目中的大多数已转移到 GAS 或 NASM。据我所知，只有 ELKS 继续使用它。

	AS86 可以在 http://www.debath.co.uk/dev86/ 中找到，在带有链接器 (ld86) 的 bin86 包中，或作为单独的存档。文档可以作为源包中的 man 页面和 as.doc 获得。如有疑问，源代码本身通常是一个很好的文档：尽管它的注释不是很好，但编程风格很直接。AS86 是许多 BSD 和 Linux 发行版的一部分。
	AS86 主要是一个 16 位汇编器。3.2.5. 宏支持将 AS86 与 BCC 一起使用这是使用 BCC 将asm 转换为 a.out.o对象和 %.o %.l: %.s bcc -3 -G -c -A-d -A-l -A$*.l -o $*.o $< .l列表的 GNU Makefile 条目, 删除%.l-A-l，如果你不想要任何列表。如果你想要使用 a.out 以外的其他格式，你可以查阅 BCC 文档中关于其他支持格式的内容，和/或 使用 GNU binutils 包中的 objcopy 工具。

3.4.2. YASM

YASM 是 NASM 汇编器的完全重写版本，采用“新” BSD 许可证。它从一开始就被设计为支持多种语法（例如，NASM、TASM、GAS 等），以及多种输出对象格式，包括 COFF、Win32 和 Mach-O。整体设计的另一个主要模块是优化器模块。

3.4.3. FASM

FASM（flat assembler，平面汇编器）是一个快速、高效的 80x86 汇编器，运行在“平面实模式”下。与许多其他 80x86 汇编器不同，FASM 仅要求源代码包含它真正需要的信息。它用自身编写，体积非常小且速度很快。它可以在 DOS/Windows/Linux 上运行，并可以生成平面二进制文件、DOS EXE、Win32 PE、COFF 和 Linux ELF 输出。请访问 http://flatassembler.net。

3.4.4. OSIMPA (SHASM)

osimpa 是一个用于 Intel 80386 处理器及其后续产品的汇编器，完全用 GNU Bash 命令解释器 shell 编写。osimpa 的前身是 shasm。osimpa 经过了大量清理，可以创建有用的 Linux ELF 可执行文件，并具有各种类似 HLL 的扩展和程序员便利命令。

（当然）它比其他汇编器慢。它有自己的语法（并使用自己的名称来表示 x86 操作码）。包含相当好的文档。请查看：ftp://linux01.gwdg.de/pub/cLIeNUX/interim/（访问受密码控制）。你可能不会经常使用它，但至少它值得你作为一个有趣的想法而关注。

3.4.5. AASM

Aasm 是一个先进的汇编器，旨在支持多种目标架构。它被设计为易于扩展，并且应该被认为是为每个新的目标 CPU 和二进制文件格式进行单体汇编器开发的良好替代方案。

Aasm 应该通过提供一组高级功能（包括符号作用域、表达式引擎、大整数支持、宏功能、大量且准确的警告消息）来使汇编编程对开发人员来说更容易。其动态模块化架构使 Aasm 能够通过利用动态库来扩展其功能集。

输入模块支持 Intel 语法（如 nasm、tasm、masm 等）。x86 汇编器模块支持所有直到 P6 的操作码，包括 MMX、SSE 和 3DNow! 扩展。F-CPU 和 SPARC 汇编器模块正在开发中。多个输出模块可用于 ELF、COFF、IntelHex 和原始二进制格式。

http://savannah.nongnu.org/projects/aasm/

3.4.6. TDASM

表驱动汇编器 (TDASM) 是一个免费的、可移植的交叉汇编器，适用于任何类型的汇编语言。应该可以使用它作为任何目标微处理器的编译器，使用一个定义编译过程的表。

它可以从 http://www.penguin.cz/~niki/tdasm/ 获取，但似乎不再积极维护。

3.4.7. HLA

HLA 是一种高级汇编语言。它使用类似于高级语言的语法（类似于 Pascal、C/C++ 和其他 HLL）来进行变量声明、过程声明和过程调用。它对标准机器指令使用修改后的汇编语言语法。它还提供了几个高级语言风格的控制结构（if、while、repeat..until 等），可以帮助你编写更具可读性的代码。

HLA 是免费的，并附带源代码，提供 Linux 和 Win32 版本。在 Win32 上，你需要 MASM 和 32 位的 MS-link 版本；在 Linux 上，你需要 GAS，因为 HLA 生成指定的汇编代码并使用该汇编器进行最终汇编和链接。

3.4.8. TALC

TALC 是另一个基于 MASM/Win32 的免费编译器（但是它支持 ELF 输出，是吗？）。

TAL 代表类型汇编语言 (Typed Assembly Language)。它使用类型注释、内存管理原语和一组健全的类型规则扩展了传统的无类型汇编语言，以保证 TAL 程序的内存安全、控制流安全和类型安全。此外，类型构造具有足够的表达力来编码大多数源语言编程特性，包括记录和结构、数组、高阶和多态函数、异常、抽象数据类型、子类型和模块。同样重要的是，TAL 足够灵活，可以允许许多底层编译器优化。因此，TAL 是类型导向编译器的理想目标平台，这些编译器希望生成可验证的安全代码，用于安全移动代码应用程序或可扩展操作系统内核。

3.4.9. Free Pascal

Free Pascal 有一个内部 32 位汇编器（基于 NASM 表），并且有一个可切换的输出，允许

• 二进制 (ELF 和 coff，当交叉编译 .o 时) 输出

• NASM

• MASM

• TASM

• AS (aout,coff, elf32)

MASM 和 TASM 输出的调试效果不如其他两个，但有时可能很方便。

汇编器的外观和感觉基于 Turbo Pascal 的内部 BASM，IDE 支持类似的语法高亮，并且 FPC 可以完全与 gcc 集成（在 C 级别，而不是 C++）。

使用虚拟 RTL，甚至可以生成纯汇编程序。

3.4.10. Win32Forth 汇编器

Win32Forth 是一个免费的 32 位 ANS FORTH 系统，可以在 Win32s、Win95、Win/NT 下成功运行。它包含一个免费的 32 位汇编器（前缀或后缀语法），集成到反射式 FORTH 语言中。宏处理通过反射式语言 FORTH 的全部功能完成；但是，唯一支持的输入和输出上下文是 Win32For 本身（没有转储.obj文件，但你当然可以自己添加该功能）。请在 ftp://ftp.forth.org/pub/Forth/Compilers/native/windows/Win32For/ 找到它。

3.4.11. Terse

Terse 是一个编程工具，为 x86 系列提供了最紧凑的汇编器语法！然而，它是邪恶的专有软件。据说曾经有一个免费克隆的项目，但在毫无价值地声称语法将归原始作者所有之后被放弃了。因此，如果你正在寻找与汇编黑客相关的绝妙编程项目，我邀请你开发一个 terse 语法前端到 NASM，如果你喜欢那种语法的话。

作为一个有趣的历史评论，在 comp.compilers 上，

1999/07/11 19:36:51, 版主 写道

“没有 理由 汇编器 必须 有 糟糕的 语法。  大约
30 年前 我 使用过 Niklaus Wirth 的 PL360， 它 基本上 是一个 S/360
汇编器， 带有 Algol 语法 和 一点 语法糖， 比如 while
循环， 它 变成了 明显的 分支。  它 真的是 一个
汇编器， 例如， 你 必须 写出 你的 表达式， 并 显式地
将 值 赋值给 寄存器， 但 它 很棒。  Wirth 用它来
编写 Algol W， 一个 小巧快速的 Algol 子集， 它是 一个 前身
Pascal。  正如 经常 发生的情况， Algol W 是一个 重要的
改进， 超越了 许多 它的 继任者。 -John”

3.4.12. 非免费和/或非 32 位 x86 汇编器

你可以在 Raymond Moon 的 x86 汇编 FAQ 中找到更多关于它们的信息，以及 x86 汇编编程的基础知识。

请注意，所有基于 DOS 的汇编器都应该在 Linux DOS 模拟器以及其他类似的模拟器中工作，因此如果你已经拥有一个，你仍然可以在真实的操作系统中使用它。最近的基于 DOS 的汇编器也支持 COFF 和/或其他 GNU BFD 库支持的对象文件格式，因此你可以将它们与你的免费 32 位工具一起使用，或许可以使用 GNU objcopy（binutils 的一部分）作为转换过滤器。

4.1.1. CPP

CPP 确实不是很富有表现力，但对于简单的东西来说足够了，它是标准的，并且被 GCC 透明地调用。

作为其局限性的一个例子，你无法声明对象，以便在声明块末尾自动调用析构函数；你没有分支或作用域等。

CPP 随任何 C 编译器一起提供。但是，考虑到它有多么平庸，如果碰巧你可以不用 C 也能做到，那就远离它。

4.1.2. M4

M4 为你提供了宏处理的全部功能，以及图灵等价语言、递归、正则表达式等。你可以用它做任何 CPP 做不到的事情。

请参阅 macro4th (this4th) 作为使用 m4 进行高级宏编程的示例。

但是，其功能失调的引用和取消引用语义迫使你使用显式的延续传递尾递归宏风格，如果你想进行高级宏编程（这让人想起 TeX -- 顺便说一句，有人尝试将 TeX 用作排版以外的任何东西的宏处理器吗？）。这并不比 CPP 更糟，CPP 无论如何都不允许引用和递归。

要获取的正确 M4 版本是GNU m4它具有最多的功能，并且所有版本中错误或限制最少。m4 被设计为除了最简单的用途之外都很慢，这对于大多数汇编编程来说可能仍然可以接受（你不是在编写百万行汇编程序，是吗？）。

4.1.3. 使用你自己的过滤器进行宏处理

你可以使用常用工具（perl、awk、sed 等）编写你自己的简单宏扩展过滤器。它可以相当快地完成，并且你可以控制一切。但是，当然，宏处理中的强大功能意味着“艰难的方式”。

4.2.1. 来自编译器的后端

像 GCC、SML/NJ、Objective CAML、MIT-Scheme、CMUCL 等编译器，都有自己的通用汇编器后端，如果你打算从相应的语言或你修改的语言中半自动生成代码，你可以选择使用它们：与其编写出色的汇编代码，不如修改编译器，使其转储出色的汇编代码！

4.2.2. 新泽西机器代码工具包

有一个项目，使用编程语言 Icon（以及实验性的 ML 版本），旨在构建用于生成汇编操作代码的基础。请访问 http://www.eecs.harvard.edu/~nr/toolkit/ 了解更多信息。

4.2.3. TUNES

自由反射计算系统 TUNES 项目正在开发自己的汇编器作为 Scheme 语言的扩展，作为其开发过程的一部分。它目前还完全无法运行，但欢迎提供帮助。

汇编器操作抽象语法树，因此它可以同样地用作汇编语法转换器、反汇编器、通用汇编器/编译器后端等的基础。此外，真正的语言 Scheme 的全部功能使其在宏处理/元编程方面无可匹敌。

5.1.1. 链接到 GCC

如果你正在开发混合 C-asm 项目，这是首选方法。查看 GCC 文档和 Linux 内核中的示例.s通过 gas 的文件（而不是通过 as86 的文件）。

32 位参数以相反的语法顺序压入堆栈（因此以正确的顺序访问/弹出），在 32 位近返回地址之上。%ebp, %esi, %edi, %ebx是被调用者保存的，其他寄存器是调用者保存的；%eax用于保存结果，或%edx:%eax用于 64 位结果。

FP 栈：我不确定，但我认为结果在st(0)中，整个堆栈由调用者保存。

请注意，GCC 有选项可以通过保留寄存器、将参数放在寄存器中、不假设 FPU 等来修改调用约定。查看 i386.info页面。

请注意，你必须为将遵循标准 GCC 调用约定的函数声明cdecl目录中的二进制版本。也应该可以作为regparm(0)属性。请参阅C 扩展::扩展汇编:GCC 信息页面中的部分。另请参阅 Linux 如何定义其asmlinkage宏。

5.1.2. ELF vs a.out 问题

一些 C 编译器在每个符号前添加下划线，而另一些则不添加。

特别是，Linux a.out GCC 会添加这样的前缀，而 Linux ELF GCC 则不会。

如果你需要同时处理这两种行为，请查看现有软件包的做法。例如，获取旧的 Linux 源代码树，Elk、qthreads 或 OCaml。

你还可以通过插入如下语句来覆盖隐式的 C->asm 重命名

	void foo asm("bar") (void);

请注意，来自 binutils 包的 objcopy 实用程序应该允许您将 a.out 对象转换为 ELF 对象，并且在某些情况下，也许反之亦然。更一般地说，它将进行大量的文件格式转换。

5.1.3. 直接 Linux 系统调用

通常你会听到使用 C 库 (libc) 是唯一的方法，而直接系统调用是不好的。 这在某种程度上是真的。一般来说，你必须知道 libc 并非神圣不可侵犯，而且在大多数情况下，它只是做一些检查，然后调用内核，然后设置 errno。 你也可以在你的程序中轻松地做到这一点（如果需要），并且你的程序会小几十倍，这也会提高性能，仅仅因为你没有使用共享库（静态二进制文件更快）。 在汇编编程中使用或不使用 libc 更多的是品味/信仰问题，而不是实际问题。 记住，Linux 的目标是符合 POSIX 标准，libc 也是如此。 这意味着几乎所有 libc “系统调用”的语法都与真正的内核系统调用的语法完全匹配（反之亦然）。 此外，GNU libc(glibc) 的版本变得越来越慢，并且消耗越来越多的内存；因此，使用直接系统调用的情况变得非常普遍。 然而，抛弃 libc 的主要缺点是，你可能需要自己实现几个 libc 特定的函数（不仅仅是系统调用包装器）（printf()和类似的函数），你准备好了，不是吗？ :-)

以下是直接系统调用优缺点的总结。

优点

• 尽可能小的尺寸；从系统中挤出最后一个字节

• 尽可能高的速度；从你最喜欢的基准测试中挤出周期

• 完全控制：你可以使你的程序/库适应你的特定语言或内存需求或其他任何需求

• 不受 libc 垃圾代码的污染

• 不受 C 调用约定的污染（如果你正在开发自己的语言或环境）

• 静态二进制文件使你独立于 libc 升级或崩溃，或来自悬空的#!解释器路径（并且速度更快）

• 仅仅为了乐趣（汇编编程难道不会让你感到兴奋吗？）

缺点

• 如果你的计算机上的任何其他程序使用了 libc，那么复制 libc 代码实际上会浪费内存，而不是节省内存。

• 在许多静态二进制文件中冗余实现的服务是一种内存浪费。 但是你可以将你的 libc 替代品制作成共享库。

• 通过某种字节码、字码或结构解释器来节省空间比用汇编编写所有内容要好得多。（解释器本身可以用 C 或汇编编写。）保持多个二进制文件小的最佳方法不是拥有多个二进制文件，而是拥有一个解释器进程来处理带有#!前缀的文件。 这就是 OCaml 在字码模式下使用时的工作方式（与优化的本机代码模式相反），并且它与使用 libc 兼容。 这也是 Tom Christiansen 的 Perl PowerTools 对 unix 实用程序的重新实现的工作方式。 最后，最后一种保持文件小的且不依赖于带有硬编码路径的外部文件（无论是库还是解释器）的方法是只拥有一个二进制文件，并拥有指向它的多个命名硬链接或软链接：同一个二进制文件将以最佳空间提供你需要的一切，而没有子例程或无用的二进制头文件的冗余；它将根据它的argv[0]来调度其特定行为； 如果它没有以可识别的名称调用，它可能会默认为 shell，因此也可用作解释器！

• 你无法从 libc 提供的许多功能中受益，除了仅仅是 linux 系统调用：也就是说，手册页第 3 节中描述的功能，而不是第 2 节，例如 malloc、线程、locale、密码、高级网络管理等。

• 因此，你可能不得不重新实现 libc 的大部分，从printf()到malloc()和gethostbyname。 这与 libc 的工作是冗余的，有时可能会非常无聊。 请注意，有些人已经重新实现了“轻量级”的 libc 部分替代品——去看看它们！（Redhat 的 minilibc，Rick Hohensee 的 libsys，Felix von Leitner 的 dietlibc，asmutils 项目正在开发纯汇编 libc）

• 静态库阻止你从 libc 升级以及 libc 附加组件（例如 zlibc 包）中受益，zlibc 包可以对 gzip 压缩文件进行即时透明解压缩。

• 与系统调用的成本相比，libc 添加的少量指令可能是非常小的速度开销。 如果速度是一个问题，那么你的主要问题在于你对系统调用的使用，而不是它们的包装器的实现。

• 当在 Linux 的微内核版本（如 L4Linux）中运行时，使用标准汇编 API 进行系统调用比使用 libc API 慢得多，L4Linux 有自己更快的调用约定，并且在使用标准调用约定（L4Linux 附带使用其系统调用 API 重新编译的 libc；当然，你也可以使用他们的 API 重新编译你的代码）。

• 有关一般速度优化问题，请参阅之前的讨论。

• 如果系统调用对你来说太慢了，你可能想要破解内核源代码（用 C 语言编写），而不是停留在用户空间。

如果你已经权衡了上述优缺点，并且仍然想使用直接系统调用，那么这里有一些建议。

• 你可以通过包含asm/unistd.h，并使用提供的宏，以可移植的方式在 C 语言中轻松定义你的系统调用函数（而不是使用不可移植的汇编）。

• 既然你试图替换它，那就去获取 libc 的源代码，并理解它们。（如果你认为你可以做得更好，那么请向作者发送反馈！）

• 作为纯汇编代码的示例，它可以完成你想要的一切，请检查 .

基本上，你发出一个int 0x80，带有__NR_syscallname 编号（来自asm/unistd.h）在等等，而不是仅仅是中，参数（最多六个）在ebx, ecx, （将寄存器, esi, edi, ebp中，分别。

结果在等等，而不是仅仅是中返回，负结果表示错误，其相反值是 libc 将放入errno中的值。 用户堆栈不会被触及，因此在进行系统调用时，你不需要有一个有效的堆栈。

在ebp中传递第六个参数出现在 Linux 2.4 中，之前的 Linux 版本仅理解寄存器中的 5 个参数。

《Linux 内核内幕》，尤其是《i386 架构上系统调用是如何实现的？》章节将为你提供更全面的概述。

至于进程启动时传递的调用参数，一般原则是堆栈最初包含参数的数量argc，然后是指针列表，构成*argv，然后是以 null 结尾的 null 结尾序列variable=value字符串，用于environ环境。 有关更多详细信息，请检查 ，阅读你的 libc 中的 C 启动代码源文件（crt0.S目录中的二进制版本。也应该可以作为crt1.S），或 Linux 内核中的那些源文件（exec.c和binfmt_*.c在linux/fs/).

5.1.4. Linux 下的硬件 I/O

如果你想在 Linux 下执行直接端口 I/O，要么它是一些非常简单的东西，不需要 OS 仲裁，你应该查看IO-Port-Programmingmini-HOWTO；要么它需要内核设备驱动程序，你应该尝试了解更多关于内核黑客技术、设备驱动程序开发、内核模块等的信息，LDP 提供了其他优秀的 HOWTO 和文档。

特别是，如果你的目标是图形编程，那么请加入 GGI 或 XFree86 项目之一。

有些人甚至做得更好，用解释型特定领域语言 GAL 编写小型且稳健的 XFree86 驱动程序，并通过部分求值实现了手写 C 驱动程序的效率（驱动程序不仅不是用汇编编写的，甚至不是用 C 编写的！）。 问题在于他们用于实现效率的部分求值器不是自由软件。 有人愿意替换它吗？

无论如何，在所有这些情况下，使用带有来自linux/asm/*.h的宏的 GCC 内联汇编比编写完整的汇编源文件要好。

5.1.5. 从 Linux/i386 访问 16 位驱动程序

这种事情在理论上是可能的（证明：看看 DOSEMU 如何选择性地授予程序硬件端口访问权限），并且我听说有传言说有人在某个地方确实做到了（在 PCI 驱动程序中？一些 VESA 访问的东西？ISA PnP？不知道）。 如果你有关于此的更精确的信息，我们将非常欢迎。 无论如何，查找更多信息的良好地方是 Linux 内核源代码、DOSEMU 源代码以及 Linux 下各种低级程序的源代码。（如果 GGI 支持 VESA，也许可以看看 GGI）。

基本上，你必须使用 16 位保护模式或 vm86 模式。

前者设置起来更简单，但仅适用于行为良好的代码，这些代码不会进行任何类型的段算术或绝对段寻址（特别是寻址段 0），除非偶然情况下，所有使用的段都可以预先在 LDT 中设置。

后者允许与原始 16 位环境具有更高的“兼容性”，但需要更复杂的处理。

在这两种情况下，在你跳转到 16 位代码之前，你必须

• 从/dev/mem到你的进程地址空间，mmap 16 位代码中使用的任何绝对地址（例如 ROM、视频缓冲区、DMA 目标和内存映射 I/O），

• 设置 LDT 和/或 vm86 模式监视器。

• 从内核获取正确的 I/O 权限（参见上一节）

再次强调，仔细阅读为 DOSEMU 项目贡献的代码的源代码，特别是用于在 Linux/i386 下运行 ELKS 和/或简单.COM程序的这些小型模拟器。

6.1.1. 你需要的工具

首先，你需要汇编器（编译器）—— nasm 或 gas。

其次，你需要一个链接器——ld，因为汇编器只生成目标代码。几乎所有发行版都带有 gas 和 ld，它们在 binutils 软件包中。

至于 nasm，你可能需要从 nasm 站点下载并安装 Linux 的二进制软件包和文档；请注意，一些发行版（Stampede、Debian、SuSe、Mandrake）已经带有 nasm，请先检查。

如果你打算深入研究，你应该也安装操作系统的头文件，如果可能的话，安装内核源代码。

6.2.1. 程序布局

Linux 是 32 位的，运行在保护模式下，具有平面内存模型，并使用 ELF 格式的二进制文件。

一个程序可以被划分为节 (sections).text用于你的代码（只读），.data用于你的数据（读写），.bss用于未初始化的数据（读写）；实际上可能还有一些其他的标准节，以及一些用户自定义的节，但很少需要使用它们，而且它们不在此处讨论范围内。一个程序必须至少有一个.text节。

现在我们将编写我们的第一个程序。这里是示例代码

6.2.2. NASM (hello.asm)

section .text                   ;section declaration

                                ;we must export the entry point to the ELF linker or
    global  _start              ;loader. They conventionally recognize _start as their
			                          ;entry point. Use ld -e foo to override the default.

_start:

                                ;write our string to stdout

    mov     edx,len             ;third argument: message length
    mov     ecx,msg             ;second argument: pointer to message to write
    mov     ebx,1               ;first argument: file handle (stdout)
    mov     eax,4               ;system call number (sys_write)
    int     0x80                ;call kernel

                                ;and exit

  	mov     ebx,0               ;first syscall argument: exit code
    mov     eax,1               ;system call number (sys_exit)
    int     0x80                ;call kernel

section .data                   ;section declaration

msg db      "Hello, world!",0xa ;our dear string
len equ     $ - msg             ;length of our dear string

6.2.3. GAS (hello.S)

.text                           # section declaration

			                          # we must export the entry point to the ELF linker or
    .global _start              # loader. They conventionally recognize _start as their
			                          # entry point. Use ld -e foo to override the default.

_start:

                                # write our string to stdout

	  movl    $len,%edx           # third argument: message length
	  movl    $msg,%ecx           # second argument: pointer to message to write
	  movl    $1,%ebx             # first argument: file handle (stdout)
	  movl    $4,%eax             # system call number (sys_write)
	  int     $0x80               # call kernel

                                # and exit

	  movl    $0,%ebx             # first argument: exit code
	  movl    $1,%eax             # system call number (sys_exit)
	  int     $0x80               # call kernel

.data                           # section declaration

msg:
	.ascii    "Hello, world!\n"   # our dear string
	len = . - msg                 # length of our dear string

6.3.1. 生成目标代码

构建可执行文件的第一步是从源代码编译（或汇编）目标文件

对于 nasm 示例

$ nasm -f elf hello.asm

对于 gas 示例

$ as -o hello.o hello.S

这会生成hello.o目标文件。

6.3.2. 生成可执行文件

第二步是通过调用链接器，从目标文件生成可执行文件本身

$ ld -s -o hello hello.o

这最终会构建hello可执行文件。

嘿，试试运行它... 成功了吗？ 就这样。 很简单。