如何写一个简单的编译器：从架构到落地的实践指南

一、为什么值得亲手写一个编译器

对多数开发者而言，编译器是日常最熟悉又最陌生的工具：每天都在用，却很少有机会看清其内部机制。亲手实现一个编译器，是消除这种“黑盒感”最有效的途径。以一个切实可行的目标为例——用 C++ 实现一个迷你 C 编译器：一方面可以逼自己逐条啃下 C11 标准，把语言规则从“直觉”沉淀为“条文”；另一方面，这种约束明确、规模适中（约一万行代码）的项目，也是锤炼 C++ 工程能力的绝佳载体。

在这样的项目中，你会完整经历从源码文本到可执行文件的全部环节：预处理、词法分析、语法分析、语义与类型检查，直至生成 x86-64 汇编。更重要的是，你将被迫回答那些平时被编译器“代劳”的问题：隐式类型转换发生在哪里？同名标识符如何按作用域解析？函数参数按什么约定传递？

二、编译器的整体架构：一条五阶段流水线

无论工业级编译器还是教学级实现，主干结构都可以抽象为一条流水线：

源代码 → 预处理 → 词法分析(Token流) → 语法分析(AST) → 语义与类型检查 → 汇编代码生成

各阶段职责如下：

1. 预处理器：处理 #include、#define、条件编译等指令，产出展开后的翻译单元。它本质上是独立的宏语言解释器，复杂度常被低估。
2. 词法分析：把字符流切分为 token（关键字、标识符、常量、运算符、标点），并携带行列位置信息，为后续诊断定位服务。
3. 语法分析：通常采用递归下降法，按语言文法把 token 流组织成抽象语法树（AST）。
4. 语义与类型检查：在 AST 上完成作用域解析、类型推导、隐式转换插入与常量表达式求值，并输出诊断信息。错误提示建议向主流编译器的风格看齐：精确指出行列位置、说明“期望什么、实际看到什么”。
5. 代码生成：把 AST 翻译为汇编文本，交给系统自带的汇编器与链接器收尾。

一条关键经验是：先保证正确，再谈优化。生成汇编时很容易忍不住手写寄存器分配、窥孔优化、指令选择，结果陷入无休止的手动优化。正确姿势是先做“笨但正确”的翻译器，等全部测试通过后，再针对收益最大的少数环节做优化。

三、方法论：两步走 + 逐特性迭代

第一步：以最快速度让编译器“活”过来

目标只有一个——让下面这段最小程序被正确编译、汇编、链接，并以退出码 0 结束：

int main(int argc, char **argv)
{
    int i;
    return 0;
}

这一步的要义是打通全链路，而非支持多少特性。你甚至可以暂缓严格的类型检查，只求产出一段带 main 标签和 ret 指令的汇编，并用系统工具链链接出可执行文件。当你运行程序并看到退出码为 0 时，项目就从“想法”变成了“能跑的编译器”——这种正反馈对个人项目至关重要。

第二步：以最快速度看到 hello, world

从 return 0 到 printf("hello, world\n")，跨越的是函数调用、字符串字面量、外部符号声明与调用约定。打通之后，编译器开始与标准库和真实世界交互，后续每实现一个新特性都能立刻看到输出效果。

第三步：对照标准逐特性推进，同步补单元测试

有了前两步搭好的骨架，剩下的是“体力加脑力”活：打开语言标准，按章节把声明、表达式、语句、预处理逐个补齐，每实现一个特性就配一组单元测试。工作量确实不小，但由于链路已通、调试手段已建立，推进速度远比想象中快。范围控制同样重要：像变长数组这类实现成本高、收益偏低的特性，果断舍弃并不损害项目价值。

四、各阶段实现要点

4.1 词法分析：细心大于技巧

这个阶段几乎没有算法难度，却决定后续所有诊断的可用性。要点包括：token 携带文件、行、列三元组信息；正确处理转义字符与相邻字符串字面量拼接；区分数字常量的进制与类型后缀。建议为词法器单独编写密集的单元测试——它的任何缺陷都会以诡异方式在上游暴露。

4.2 语法分析：递归下降的“甜点区”

C 的文法非常适合手写递归下降：每个非终结符对应一个函数，表达式按运算优先级分层。实现时直接对照标准附录的文法产生式逐条翻译；遇到二义性（如 typedef 名与普通标识符的区分）时，通过符号表查询交给语义层辅助判定。AST 建议采用“基类 + 派生类”设计，将表达式、声明、语句分层建模。

4.3 语义检查：诊断质量决定开发体验

类型检查的核心是维护作用域栈式的符号表，以及一套类型运算规则（整型提升、寻常算术转换、指针兼容性）。这一阶段最值得投入的是错误信息本身：报错给出行列号、截取源码片段、写明期望与实际类型。向成熟编译器的提示风格看齐，能让自测效率成倍提升。

4.4 预处理器：被低估的硬骨头

对象式宏、函数式宏、# 与 ## 运算符、条件编译、文件包含，每一项都有标准明文的边界情况。建议把它设计成独立于主编译流程的一个阶段，先在文本层面完成展开，再交给词法分析器。

4.5 代码生成：克制优化冲动

再次强调：先用最直白的策略生成正确代码——表达式结果一律落栈、局部变量一律分配栈槽、临时结果物化为具名临时变量。之后再逐步引入常量折叠、简单寄存器缓存等优化；每引入一项，必须保证既有测试全部通过。

五、用趣味用例驱动开发

测试未必枯燥，几组“好玩”的用例反而能覆盖大量特性组合。

5.1 心形曲线：一次考察浮点、嵌套循环与库函数

#include <stdio.h>
int main()
{
    for (float y = 1.5f; y > -1.5f; y -= 0.1f) {
        for (float x = -1.5f; x < 1.5f; x += 0.05f) {
            float a = x*x + y*y - 1;
            putchar(a*a*a - x*x*y*y*y <= 0.0f ? '*' : ' ');
        }
        putchar('\n');
    }
}

短短十余行，同时覆盖浮点运算、嵌套循环、三元表达式与标准库函数调用，是极佳的里程碑用例。

5.2 复合字面量：类型双关的正确姿势

想在 C 里查看浮点数的位级表示，传统写法是：

float f = 1.5;
int i = *(int *)&f;

一些主流编译器在较高优化级别下，会对这种写法给出“违反严格别名规则”的警告，甚至做出改变语义的激进优化。C11 的复合字面量配合匿名联合提供了更稳妥的方案：

#define CAST(s_t, d_t, sv) \
    ((union { s_t sv; d_t dv; }){ sv }.dv)
float f = 1.5;
int i = CAST(float, int, f);

经由联合体访问，编译器被明确告知这是一次合法的类型双关。更有意思的是，这个宏在 C 中起到了“模板”的作用——同一套定义适配任意源与目标类型的组合。若你的实现正确支持了复合字面量与匿名联合，它就是绝佳的验收用例。

5.3 Unicode 标识符：让“中文编程”跑起来

C11 起标识符允许使用 Unicode 字符，配合宏做一层词汇替换，即可写出“汉化”的 C 程序：

#define 整型 int
#define 输出 printf
#define 主函数 main
#define 返回 return
#define 定义 typedef
#define 不可变 const
#define 字符 char
#define 指针 *
定义 不可变 字符 指针 字面值;
整型 主函数()
{
    字面值 诗句 = "床前明月光，疑是地上霜";
    输出("%s\n", 诗句);
    返回 0;
}

这类用例不只是猎奇：它同时考验词法器对多字节字符的处理、标识符合法性判定，以及预处理与词法分析的衔接顺序。

六、几条工程建议

1. 测试与特性同步生长：不要“先写完再测”。实现一个特性立即补测试，回归成本才会最低。
2. 把标准当规格书：动手前先读条文的字面要求，避免凭直觉“发明”语义。
3. 诊断信息是第一生产力：位置准确、措辞可读的报错，价值不亚于编译速度。
4. 敢于砍范围：明确“不做什么”与明确“做什么”同样重要。

七、总结

写一个简单的编译器，真正的门槛不在算法深度，而在工程方法：先用最小程序打通全链路，再借语言标准与单元测试逐特性迭代。当你亲手编译出的程序在屏幕上打印出心形图案时，“编译器”便不再是黑盒，而是一套你完全理解、可以亲手驾驭的、逻辑严密的翻译系统。