Name: 图解编译原理
Author: MiniMax-M3

初识编译器：从源代码到机器语言的魔法之旅

打开终端，输入 `gcc hello.c -o hello`，按下回车，几秒后屏幕上出现一个可执行文件。这一行命令的背后，藏着一套已经运行了七十多年的精密机器——编译器。它把人类写得"像文章一样"的代码，变成计算机唯一能听懂的 0 和 1。

但编译器究竟做了哪些事？为什么它能正确处理各种语法错误？为什么有些语言跑得快、有些语言跑得慢？这一章，我们就来一一回答这些问题，并亲手把"编译"这条黑盒拆开来看一看。

一次真实的编译旅程：Hello World 背后的秘密

我们从一个最简单、但故意不那么"裸"的 C 程序开始。请准备一个文本编辑器和一个终端（Linux、macOS 或 WSL 上的 bash 都可以），跟着下面的步骤动手做一遍。这一次实操的目的，是让你直观看到"编译"的输入、输出和中间过程。

第一步：写一段代码

新建一个文件，命名为 `hello.c`，输入以下内容：

```c #include <stdio.h>

int add(int a, int b) { return a + b; }

int main() { int sum = add(1, 2); printf("Hello, Compiler! 1 + 2 = %d\n", sum); return 0; } ```

这个程序刻意写得"不那么简单"——除了熟悉的 `printf` 输出，我们还定义了一个 `add` 函数并在 `main` 中调用它。这样做的目的，是让你看清楚编译过程究竟涉及多少个独立的"翻译"步骤。一个只调用 `printf` 的程序其实会把核心过程隐藏起来；加入自定义函数后，链接器的工作才能显式地体现出来。

第二步：执行一次完整的编译

在终端中执行：

```bash gcc hello.c -o hello ```

如果一切顺利，当前目录下会出现一个名为 `hello` 的可执行文件。运行它：

```bash ./hello ```

屏幕会打印：

``` Hello, Compiler! 1 + 2 = 3 ```

恭喜你，刚刚已经完成了一次完整的编译。但故事才刚刚开始——这一行命令的背后，GCC 其实悄悄帮我们做了四件事：预处理、编译、汇编、链接。

第三步：把"黑盒"拆开来看

我们可以用 GCC 的 `-v` 选项（verbose）让编译器自己说出每一步的细节：

```bash gcc -v hello.c -o hello 2>&1 | tail -30 ```

你会看到类似这样的输出（具体路径因系统而异）：

``` collect2 version 11.4.0 /usr/bin/ld -pie --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 \ /usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/Scrt1.o \ /usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/crti.o \ /usr/lib/gcc/x86_64-linux-gnu/11/crtbeginS.o \ -L/usr/lib/gcc/x86_64-linux-gnu/11 \ -L/usr/lib/x86_64-linux-gnu/... \ /tmp/ccXXXXXX.o -lgcc --as-needed -lgcc_s --no-as-needed -lc ... ```

这是被叫做 `ld` 的程序——链接器，正在把若干目标文件、启动文件、标准库合并成最终的可执行文件。`collect2` 是 GCC 用来调用 `ld` 的一个包装。

我们也可以让 GCC 在中间停下，把每一步的产物都保存下来。用 `-save-temps` 选项：

```bash gcc -save-temps hello.c -o hello ls ```

你会看到目录下多出了几个新文件：

`hello.i`：预处理之后的源代码
`hello.s`：编译器生成的汇编代码
`hello.o`：汇编器生成的目标文件
`hello`：最终的可执行文件

我们可以分别看看它们的内容。比如 `hello.i`：

```bash head -30 hello.i ```

会发现原本只有十几行的代码，膨胀成了几百甚至上千行——`#include <stdio.h>` 被替换成了 `stdio.h` 的全部内容，还多了很多 `#define`、`#pragma` 之类的预处理指令。这说明预处理阶段已经把"高层"的代码展开成了更"低层"的等价形式，宏替换、头文件包含、条件编译都在这一步完成。

再看 `hello.s`：

```bash cat hello.s ```

你会看到汇编语言——比 C 低、比机器语言高的一层。最显眼的就是 `_main:` 这个标签，下面跟着 `pushq %rbp`、`movl $1, %edi`、`call add` 这样的指令。你写的 `add(1, 2)` 已经被翻译成了 `call add` 这样的函数调用指令，准备让 CPU 在运行时跳转到 `add` 函数的位置去执行。

最后看 `hello.o`：

```bash file hello.o ```

它会告诉你这是 "ELF 64-bit LSB relocatable object file"，也就是"可重定位目标文件"。这个文件里包含的是几乎可以直接被 CPU 执行的机器指令，但还有一些"地址"没有最终确定——比如 `add` 函数究竟放在内存的哪个位置，要等链接器把所有 `.o` 文件合在一起时才能定下来。这种"留待最后再定"的地址，在编译原理里叫做重定位（relocation），是链接器工作的核心。

第四步：理解"分层"

通过这个实验，你已经直观地看到了编译过程的几个关键事实：

1. 编译不是一个动作，而是一条流水线。从 `.c` 到可执行文件，至少要经过预处理、编译、汇编、链接四步，每一步都有专门的程序负责。 2. 每一步的产物是下一步的输入。`.c → .i → .s → .o → 可执行文件`，层层推进。 3. 链接器承担了"组装"的工作。它把我们写的 `add`、`main`，和 `printf`、启动代码（crt0）、运行时库等合并成最终的可执行文件。 4. 目标文件不是终点。`.o` 文件本身不能运行——它依赖的外部符号还没有被解析，必须经过链接才是一个完整、可加载、可执行的程序。

下面用一张图把这个过程画出来。这张图会以各种形式反复出现在这本书的每一章里，建议你把它刻在脑子里：

```mermaid flowchart LR src["hello.c 源代码"] --> cpp["预处理器 cpp"] cpp --> i["hello.i 预处理后代码"] i --> cc1["编译器 cc1"] cc1 --> s["hello.s 汇编代码"] s --> as["汇编器 as"] as --> o["hello.o 目标文件"] o --> ld["链接器 ld"] lib["标准库 libc、crt"] --> ld ld --> exe["hello 可执行文件"] ```

记住这张图。它会以各种变体反复出现，区别只是中间的某些步骤可能被合并，或者文件名根据平台不同有所变化（比如 Windows 下是 `.obj` 而不是 `.o`）。但整体的"层层翻译、最终组装"的逻辑不会变。

什么是编译器？——从狭义到广义的解读

回到一开始的问题：编译器到底是什么？

狭义定义：翻译者

最严格、最"教科书"的定义是这样的：

> 编译器（Compiler）是一种程序，它把用某种语言（源语言）书写的源代码作为输入，翻译成与之等价、用另一种语言（目标语言）书写的代码作为输出。

按照这个定义，我们上面演示的 `gcc hello.c -o hello` 中，狭义的"编译器"其实只是 `cc1` 这一步——它把预处理后的 C 代码翻译成了汇编代码。预处理、汇编、链接都各有自己的程序（`cpp`、`as`、`ld`），严格来说不算是"编译器"。这种严格区分在编译器理论课上很有意义，但在工程上意义不大，所以我们通常把整条 `gcc hello.c -o hello` 命令统称为"编译器"。

广义定义：转换器

如果我们把视野放宽一点，会发现"翻译"这件事远不止发生在 C 语言上。比如：

**Java 编译器 `javac`**：把 `.java` 翻译成 JVM 字节码（`.class`）
**Kotlin 编译器 `kotlinc`**：把 `.kt` 翻译成 JVM 字节码
**TypeScript 编译器 `tsc`**：把 `.ts` 翻译成 JavaScript
**V8 引擎（Chrome 的 JS 引擎）**：把 JavaScript 翻译成机器码（但 V8 同时还是一个解释器，我们后面会展开讲）
**Babel**：把 ES6+ 的 JavaScript 翻译成兼容性更好的 ES5
**Webpack/Vite/Rollup**：严格说它们是打包器，但内部也涉及"代码到代码"的翻译

这些工具做的事情其实都是"翻译源代码"，只是源语言、目标语言、运行时机各不相同。因此，广义上的编译器，指任何把一种代码转换成另一种代码的程序。

> 📌 本书采用的定义：除非特别说明，本书所说的"编译器"都采用广义定义——任何以"翻译代码"为主要职责的程序，都算是编译器。

编译器 vs 解释器：两种执行哲学

一个绕不开的话题，是"编译"与"解释"的区别。

编译执行：先把整个源代码翻译成目标语言（机器码或字节码），再执行翻译后的产物。我们刚才的 C 程序就是这种模式——`gcc` 在运行前完成了所有翻译，`./hello` 时只是把已经翻译好的指令交给操作系统加载。

解释执行：逐行（或逐段）读取源代码，边读边执行，不生成独立的翻译产物。Python 的 `python script.py` 走的就是这条路。

但事情远没有这么简单。现代语言的运行时早就不是纯粹的"编译"或纯粹的"解释"了，它们通常结合两种方式：

| 语言 | 表面执行方式 | 实际做法 | |------|------------|---------| | C/C++ | 纯编译 | 全部翻译成机器码后执行 | | Go | 纯编译 | 直接编译成机器码 | | Rust | 纯编译 | 基于 LLVM 编译成机器码 | | Java | 半编译半解释 | 先编译成字节码，JVM 解释或 JIT 编译执行 | | JavaScript | 解释（过去） | 现在 V8 等引擎会做 JIT 编译 | | Python | 解释 | CPython 默认解释执行，但 PyPy 会 JIT 编译 |

从这个表里可以看出，"编译器"和"解释器"的边界正在变得模糊。更准确的说法是：编译器偏向"提前做翻译"，解释器偏向"边执行边翻译"，但两者在工程实现上常常你中有我、我中有你。本书讲解的核心技术——词法分析、语法分析、语义分析、代码生成、优化——不管是编译器还是解释器都会用到，只是出现的时机和顺序略有不同。

举个具体的例子：V8 引擎执行一段 JavaScript 时，会先把它编译成一种叫做 字节码 的中间形式（类似于 JVM 的做法），然后解释执行字节码。在执行过程中，V8 会监控哪些代码段是"热点"（hotspot），对热点代码再做一次 JIT 编译，把它直接翻译成机器码。整个流程里既有"编译"又有"解释"，混合得很深。

编译器的简史与现代生态

了解了"是什么"，我们再快速看看"从哪里来、到哪里去"。编译器的发展史，是一部和计算机科学共同成长的历史。

简史：七十年三次浪潮

第一波浪潮（1950s-1960s）：从无到有

1952 年，传奇人物 Grace Hopper 带领团队在 Eckert-Mauchly 计算机上实现了第一个编译器 A-0。它把类似数学符号的代码翻译成机器码——这被公认为编译器的鼻祖。在那个年代，"让机器自己翻译代码"是一个相当激进的想法，主流声音认为"机器只能做算数，不可能理解高级语言"。Hopper 用 A-0 终结了这场争论。

1957 年，IBM 发布的 Fortran 是第一个完整的高级编程语言。它配套的 Fortran 编译器是第一个真正意义上"完整可用"的编译器，由 John Backus 团队完成。令人惊讶的是，Fortran 编译器在那个年代就已经做了相当多的代码优化——因为当时的机器实在太慢，不优化就没法用。优化从一开始就是编译器不可或缺的一部分。

第二波浪潮（1970s-1990s）：理论成熟与开源崛起

这一时期出现了几个标志性事件：

**1970s**：编译原理的理论体系基本成型。Knuth、Hoare、Aho、Ullman 等人的著作奠定了编译器构造的形式化基础。其中 Aho、Sethi、Ullman 合著的 *Compilers: Principles, Techniques, and Tools*（俗称"龙书"）至今仍是全球编译原理课程的标准教材。
**1985 年**：GNU 启动 GCC（GNU Compiler Collection）的开发，由 Richard Stallman 发起。它最初是 GNU C Compiler，后来扩展到 C++、Fortran、Ada、Go 等几十种语言。GCC 是开源世界最重要的编译器基础设施之一，至今仍在维护，几乎所有 Linux 发行版默认带它。
**1980s-1990s**：学术界开始用 **LALR、LL(k)** 等更高效的语法分析方法。Java 出现后，编译器开始支持面向对象、泛型、反射等复杂特性。编译器的"前端理论"在这一阶段基本成熟。

第三波浪潮（2000s-至今）：模块化、LLVM 与机器学习

**2003 年**：Chris Lattner 在 UIUC 开始 LLVM 项目，目标是构建一个"模块化、可重用的编译器基础设施"。LLVM 的革命性在于：它把"中间表示（IR）"作为公开、可优化的接口，让任何人可以快速搭出一个新语言的编译器前端。
**2007 年**：Apple 资助的 Clang（基于 LLVM 的 C/C++/Objective-C 编译器）正式发布，性能和错误提示都明显优于 GCC。LLVM/Clang 生态从此成为编译器世界的主流。
**2010s 至今**：JIT（即时编译）成为 JavaScript、Java、.NET 的标配；编译器开始引入机器学习来做自动调优（autotuning）；Rust、Go、Swift、Kotlin 等现代语言都基于 LLVM 或自研的编译基础设施。AI 辅助代码补全（如 Copilot）和程序修复技术，本质上也借用了编译原理里的语法分析、类型推断思想。

现代编译器生态：四大门派

今天的编译器世界，可以大致划分为以下几大生态：

1. GCC（GNU Compiler Collection）

维护方：GNU 基金会
支持语言：C、C++、Fortran、Ada、Go、Objective-C 等
特点：成熟稳定，几乎所有 Linux 发行版默认带它
现状：仍是嵌入式、Linux 内核、众多开源项目的首选

2. LLVM / Clang

维护方：LLVM 基金会（Apple、Google 等公司资助）
支持语言：通过 LLVM，前端已经支持 C、C++、Objective-C、Swift、Rust、Go（部分）以及几十种其他语言
特点：模块化设计、诊断信息友好、许可证友好（Apache 2.0），是 Apple 全平台、众多新语言的编译基础设施

3. JVM 生态（javac、ECJ、scalac 等）

输出：JVM 字节码
代表：OpenJDK 的 javac、Eclipse 的 ECJ（Eclipse Compiler for Java）、Scala 的 scalac
特点：跨平台"一次编译到处运行"，字节码经过 JIT 后性能接近原生代码

4. V8、SpiderMonkey 等 JavaScript 引擎

维护方：Google、Mozilla 等
特点：集解释器、JIT 编译器、优化器于一身，是浏览器性能的核心

此外还有 .NET 平台的 Roslyn、Go 语言的 `go build`（自研编译器和汇编器）、Rust 的 `rustc`（基于 LLVM）等等。可以说，编译器是整个软件世界的"基础设施"——任何一种语言的兴衰，背后都有一套编译器的支撑。即使你不写编译器，每天也在和编译器打交道。

编译过程的七个经典阶段

如果你只记住一件事，请记住这个：现代编译器内部通常分为七个阶段。这个划分来自著名的"龙书"，是过去四十年所有编译器教科书的共同语言。

七阶段总览

| 阶段 | 主要任务 | 输入 | 输出 | |------|---------|------|------| | 1. 词法分析 | 把字符切成 token | 源代码字符流 | token 序列 | | 2. 语法分析 | 把 token 组装成语法树 | token 序列 | 语法树（AST） | | 3. 语义分析 | 检查类型、作用域等语义约束 | 语法树 | 标注后的语法树 | | 4. 中间代码生成 | 生成与平台无关的中间表示 | 标注后的语法树 | 中间代码（IR） | | 5. 代码优化 | 改进中间代码，提升性能 | 中间代码 | 优化后的中间代码 | | 6. 目标代码生成 | 把中间代码翻译成目标机器指令 | 优化后的中间代码 | 目标代码（汇编/机器码） | | 7. 符号表管理与错误处理 | 全程贯穿 | — | — |

第 7 个阶段其实不是一个独立的"流程节点"，而是横跨前 6 个阶段的"基础设施"。符号表记录了源代码中所有的名字（变量、函数、类型等）及其属性——比如 `int sum` 这个声明，符号表里就要记下 `sum` 是一个整型变量、当前作用域是 `main`；错误处理则在每个阶段都要进行，每一个阶段都会产生不同类型的错误信息。

下面这张图把这七个阶段画在一起，让我们对