在系统编程领域，实现一门编译器始终是深入理解语言特性的最佳途径。Zig 作为一门强调显式控制与零成本抽象的编程语言，其 comptime 求值、精确的内存管理以及与 C 的无缝互操作性，为实现编译器提供了独特的优势。本文以开源项目 paella 为例，拆解从词法分析到代码生成的全流程工程实践，提供可落地的实现参数与关键设计决策。
词法分析：Tokenizer 的 Zig 实现
词法分析器的核心任务是将源代码字符串转换为 token 流。在 Zig 中实现词法分析器，充分利用语言的结构化错误处理与内联函数特性可以显著提升性能。paella 项目采用手写递归下降词法分析器，避免了自动生成工具的复杂性，同时保持对 token 流的完全控制。
词法分析器需要处理关键字识别、整数常量解析、标识符匹配等基本任务。Zig 的 std.StaticStringMap 提供了编译时构建的关键字映射表，其查询效率接近 O (1)，适合处理 C 语言中的 int、return、if、while、for、static、extern 等保留关键字。以下是关键字映射的典型初始化方式：
pub const keywords = std.StaticStringMap(Tag).initComptime(.{
.{ "int", .type_int },
.{ "return", .keyword_return },
.{ "void", .keyword_void },
.{ "if", .keyword_if },
.{ "else", .keyword_else },
.{ "while", .keyword_while },
.{ "for", .keyword_for },
.{ "static", .keyword_static },
.{ "extern", .keyword_extern },
});
为了提升调用点的可读性，作者添加了一个 next_force 函数，将可选返回值转换为错误联合类型，避免在每个调用点重复编写 orelse return error.NotEnoughJunk 的模式匹配代码。这种封装方式体现了 Zig 对代码可维护性的重视。
语法解析：从 Token 到 AST
语法分析阶段将 token 流转换为抽象语法树（AST）。在 C 语言的完整实现中，需要处理函数声明、变量声明、表达式语句、控制流语句等多种语法结构。paella 项目将程序建模为声明列表，每个声明可以是函数定义或变量声明：
pub const Prgm = struct {
funcs: std.SegmentedList(Decl, 0),
};
pub const StorageClass = enum { static, @"extern" };
pub const FuncDecl = struct {
sc: ?StorageClass,
name: []const u8,
params: std.SegmentedList(Identifier, 0),
block: ?Block,
};
pub const VarDecl = struct {
sc: ?StorageClass,
name: Identifier,
init: ?*Expr,
};
存储类说明符（storage class specifier）的解析是 C 语法中的一个难点。C 语言允许 static int 和 int static 两种顺序，这要求解析函数能够灵活处理类型说明符与存储类说明符的任意顺序组合。paella 实现了一个 parse_storage_class 辅助函数，逐个消费 token 并根据关键字更新状态，直到遇到非类型相关的 token 为止。这种设计既符合 C 标准的语法规则，又保持了实现的简洁性。
对于块结构（block）中的语句解析，需要区分声明与表达式语句。关键逻辑是先尝试解析存储类说明符，如果成功则按声明处理，否则按语句处理：
fn parse_block_item(
arena: std.mem.Allocator,
tokens: *lexer.Tokenizer,
) Error!ast.BlockItem {
if (parse_storage_class(tokens)) |sc|
return .decl(try parse_decl(.either, arena, tokens, .{ .yes = sc }))
else |_|
return .stmt(try parse_stmt(arena, tokens));
}
这种设计利用了 parse_storage_class 会将未识别的 token 放回缓冲区的特性，避免了重复扫描。
语义分析：类型检查与符号表管理
语义分析阶段负责标识符解析、类型检查以及链接属性处理。在 paella 中，语义分析使用字符串驻留器（StringInterner）来管理标识符字符串，避免重复分配内存的同时为后续的代码生成提供稳定的引用。
符号表需要区分局部变量与全局变量。带有链接属性（linkage）的变量（static 或 extern 修饰）不进行名称 mangling，因为链接器需要通过原始名称追踪这些符号。语义分析阶段还维护了一个类型映射（TypeMap），记录每个符号的属性信息：
const Attributes = union(enum) {
func: struct {
arity: usize,
defined: bool,
global: bool,
},
static: struct {
init: Init,
global: bool,
},
local,
const Init = union(enum) {
tentative,
initial: u64,
none,
};
};
类型检查需要处理函数重声明、静态变量的 tentative 定义、外部声明等边界情况。例如，函数声明不能同时为 static 和 extern，局部函数声明不能包含函数体（定义），这些约束都在语义分析阶段验证。
中间表示与指令生成
从 AST 到可执行代码需要经过中间表示（IR）生成与目标代码生成两个阶段。paella 的 IR 设计将程序建模为顶层项（函数或静态变量），每条指令包含操作码与操作数：
pub const Prgm = struct {
items: std.ArrayListUnmanaged(TopLevel),
};
pub const TopLevel = union(enum) {
F: FuncDef,
V: StaticVar,
};
pub const FuncDef = struct {
name: Identifier,
global: bool,
params: std.ArrayListUnmanaged(Identifier),
instrs: std.ArrayListUnmanaged(Instr),
};
指令生成阶段需要处理各种寻址模式的转换。当源操作数和目标操作数都是内存位置时，需要先加载到寄存器再进行操作。为此，paella 实现了一个状态机来自动插入必要的 mov 指令：
const State = enum {
start,
mov_mem_mem,
cmp_mem_mem,
cmp_to_imm,
add_mem_mem,
sub_mem_mem,
mul_to_mem,
idiv_const,
legal,
};
对于静态变量，代码生成阶段需要将其放入 .rodata 段，并通过 data 操作数引用。这一决策基于语义分析阶段收集的类型信息，区分需要栈帧分配局部变量与需要数据段分配的静态变量。
x86-64 汇编输出与链接
最终阶段的汇编生成将 IR 转换为符合 System V AMD64 ABI 的 x86-64 汇编代码。函数 prologue 与 epilogue 的生成、参数传递约定（整数参数通过寄存器 rdi、rsi、rdx、rcx、r8、r9 传递）都需要严格遵循平台规范。
链接阶段处理外部符号解析。paella 生成的汇编代码可以直接使用 GNU Assembler 汇编并通过系统链接器（如 ld）生成可执行文件。对于包含库函数调用的程序（如 putchar），需要链接 C 标准库。
工程实践参数与监控要点
实现完整编译器时，以下参数与监控点值得关注：词法分析器应配置缓冲区大小为 4KB 至 16KB，避免频繁的字符串切片操作；语义分析阶段应追踪符号的声明顺序，以便准确检测重复定义错误；指令选择阶段需要维护一个伪寄存器到物理寄存器或栈位置的映射表，典型实现使用 std.AutoArrayHashMap 存储映射关系；代码生成阶段应监控生成的指令数量与栈帧大小，异常大的栈帧可能指示寄存器分配策略存在问题。
测试层面，建议使用 GCC 测试集（gcc testsuite）的子集验证词法与语法正确性，同时编写针对特定语言特性的单元测试，如嵌套作用域中的变量遮蔽、静态变量的链接属性、函数参数的类型检查等。
资料来源：本文工程细节参考 Abdul Rahman Sibahi 的开源项目 paella（https://github.com/asibahi/paella），该实现遵循 Nora Sandler 所著《Writing a C Compiler》一书的方法论。