编译原理实验包全解析：从词法分析到目标代码的工程实践

简介：这份资源是中国海洋大学2020年春季学期编译原理课程的实验代码合集，面向计算机专业学生及自学者，用于在理论学习之外动手实践编译器构造的完整流程。包内共74个文件，以C源码、头文件、Flex词法规则（.l）、Bison语法规则（.y）、Makefile及可执行文件为主，另附实验要求文档与测试用例，压缩包约774KB，体量轻便、结构清晰。内容覆盖词法分析、语法分析、语义分析、中间代码生成、代码优化、目标代码生成、错误处理与诊断、编译器综合八个实验，涉及二义文法处理、符号表构建、三地址码与AST等具体知识点，并配有实验目标、预期输出与评估标准说明。已有4418人学习下载，适合按实验顺序逐步复现编译流程，也可作为课程设计或编译工具链入门的参考素材。

1. 从一份“能跑通”的编译原理实验包说起

编译原理这门课，理论课听懂了，一到实验就卡壳，是很多人的真实体验。词法分析器写完了，语法分析器不知道怎么接；语法树建出来了，语义分析又不知道从哪下手；中间代码生成、目标代码生成更是像黑匣子。这份 OUC 编译原理全部实验源码，就是一套把整条编译流水线拆开摆在你面前的工程代码——从词法分析、语法分析、语义分析，到中间代码生成和目标代码生成，每个阶段都有独立可运行的模块。它适合两类人：一是正在上编译原理课、实验卡住需要对照参考的同学；二是想二次开发、把实验改造成自己课程设计或小型编译器原型的开发者。下面我按“这项目是什么、怎么跑、怎么改”的顺序，把这份源码拆给你看。

2. 项目定位与技术选型：一套分阶段可运行的编译器实验骨架

2.1 这个项目到底解决什么问题

编译原理实验最典型的痛点是“阶段割裂”。教材把编译过程分成词法、语法、语义、中间代码、目标代码几个阶段，但实验往往只让你实现其中一两个，前后怎么衔接、数据怎么传递，课上不一定讲透。这份实验包的价值在于，它把每个阶段都做成了可独立编译、可独立运行、又能串成完整流水线的模块。你可以单独跑词法分析看 token 流，也可以把词法输出喂给语法分析看语法树，再往下走语义检查和代码生成。

从工程角度看，它更像一个“教学型编译器骨架”：每个阶段有明确的输入输出约定，阶段之间通过中间数据结构（token 列表、语法树、符号表、四元式）衔接。这种设计的好处是，你改任何一个阶段，只要保持接口不变，其他阶段不用动。对于想理解“编译器到底怎么把源码变成目标代码”的人来说，这种分阶段可观测的结构，比一个黑盒式的完整编译器更有学习价值。

技术选型上，这类实验包常见做法是用 C 或 C++ 实现，因为编译原理课程本身偏系统方向，指针操作、结构体、递归下降这些内容用 C 系语言表达最直接。词法分析一般用手写状态机或正则匹配，语法分析多用递归下降或 LL(1) 预测分析，语义分析配合符号表做类型检查，中间代码生成输出四元式或三地址码，目标代码生成则常见为简单的汇编指令序列或伪代码。下面章节里涉及的具体实现，我会按这个场景下合格开发最可能采用的做法来讲，你对照自己手头的源码时，重点看接口和数据结构是否一致。

2.2 目录结构长什么样

一份完整的编译原理实验包，目录通常按“阶段 + 公共模块”组织。下面是我拆这类项目时常见的结构，你可以对照自己下载的源码看：

compiler-lab/ ├── src/ │ ├── lexer/ # 词法分析：状态机、token 定义 │ ├── parser/ # 语法分析：递归下降、语法树节点 │ ├── semantic/ # 语义分析：符号表、类型检查 │ ├── ir/ # 中间代码：四元式生成 │ ├── codegen/ # 目标代码：汇编/伪指令生成 │ └── common/ # 公共：token 结构、错误处理、工具函数 ├── test/ │ ├── lexer/ # 各阶段测试用例源码 │ ├── parser/ │ └── ... ├── Makefile # 统一构建入口 └── README.md

这个结构的关键在于common/目录。token 结构、语法树节点定义、错误码这些跨阶段共享的数据结构放在这里，各阶段模块只依赖 common，不互相依赖。这样你单独编译 lexer 时不需要把 parser 也拉进来，调试成本低很多。如果你的源码里没有这么清晰的分层，建议二次开发时先做这一步拆分，后面改起来会顺很多。

2.3 阶段之间的数据流约定

理解这份源码，核心是理解阶段之间的数据流。典型链路是：

源程序 → [词法] → token 流 → [语法] → 语法树 → [语义] → 带类型标注的语法树 + 符号表 → [中间代码] → 四元式序列 → [目标代码] → 汇编/伪指令

每个箭头都是一次“序列化 + 反序列化”的机会。常见做法是每个阶段提供一个run(input) -> output的函数，输入输出都是内存中的结构体或类。调试时你可以把中间结果打印出来，比如词法阶段输出(类型, 值, 行号)三元组，语法阶段输出带缩进的树形结构。这种可打印的中间表示，是排查“到底哪一步错了”的关键。后面避坑章节会专门讲几个因为数据流约定不一致导致的翻车场景。

3. 跑起来：从编译到单阶段验证的完整步骤

3.1 环境准备与构建

这类 C/C++ 实验包，构建方式通常有两种：Makefile 或 CMake。先看根目录有没有Makefile，有的话直接：

# 进入项目根目录 cd compiler-lab # 查看可用的构建目标 make help # 全量构建（常见默认目标） make # 如果 Makefile 支持分阶段构建 make lexer make parser

如果项目用的是 CMake，步骤是：

mkdir build && cd build cmake .. make -j4

构建失败时，先看编译器版本。老实验包常见问题是用了 C99 之前的写法，或者依赖某个特定版本的 gcc。我一般会先跑gcc --version确认，然后看报错是“语法错误”还是“链接错误”。语法错误多半是标准不匹配，可以在 Makefile 里加-std=c99或-std=c++11试试；链接错误则要看是不是某个阶段的.o没生成，或者公共模块没被正确引用。

提示：如果 Makefile 里写死了绝对路径（比如某个同学机器上的/home/xxx/...），构建会直接失败。这种情况把路径改成相对路径或$(PWD)即可，这是实验包从别人机器拷过来最常见的翻车点之一。

3.2 单阶段运行与输入输出验证

构建成功后，先别急着跑完整流水线，按阶段单独验证。以词法分析为例，常见入口是：

# 假设可执行文件在 bin/ 下，输入是一个测试源文件 ./bin/lexer test/lexer/sample1.c

预期输出是一串 token，格式可能是KEYWORD int、IDENT main、SYMBOL (这样。你要做的第一件事是对照测试用例，看 token 数量和类型对不对。如果输出为空，先检查输入文件路径对不对、文件编码是不是 UTF-8（有些实验包对中文注释处理不好，会直接崩）。

语法分析阶段通常需要词法阶段的输出作为输入。有些实现是内部直接调用词法模块，有些则是要求你先重定向：

# 方式一：内部串联，直接给源文件 ./bin/parser test/parser/sample1.c # 方式二：管道传递 token 流 ./bin/lexer test/parser/sample1.c | ./bin/parser

两种方式都要试一下，因为不同实验包的阶段耦合方式不一样。如果管道方式报“输入格式错误”，说明 parser 期望的是结构化 token 而不是纯文本，那就用方式一。这一步的验证标准是：语法树能正确打印出来，括号匹配、语句嵌套层级和源码一致。

3.3 完整流水线跑通

单阶段都通过后，跑完整链路。常见入口是一个main或driver程序：

# 完整编译流程，输出中间代码或目标代码 ./bin/compiler test/full/sample1.c # 有些项目支持指定输出阶段 ./bin/compiler --stage=ir test/full/sample1.c ./bin/compiler --stage=codegen test/full/sample1.c

跑通的标准不是“没报错”，而是“每一阶段的中间产物都符合预期”。我的习惯是加一个-v或--verbose参数（如果源码支持），把 token 流、语法树、符号表、四元式逐段打印出来，人工扫一遍。比如四元式阶段，检查(+, a, b, t1)这种格式里临时变量编号是否连续、操作数是否都在符号表里。这一步花十分钟，能省掉后面调目标代码时几个小时的迷茫。

注意：完整流水线跑通后，建议把每个测试用例的输出保存成基线文件（expected/目录），后面改代码时用diff对比，这是二次开发阶段最省事的回归手段。

4. 核心模块拆解：词法、语法、语义三段代码逐段看

4.1 词法分析：状态机与 token 结构

词法分析的核心是一个字符级状态机。下面这段是这类实验包里最常见的实现骨架，我用 C 风格伪代码写，你对照自己源码看结构：

// token 类型枚举，放在 common/token.h typedef enum { TOK_INT, TOK_IDENT, TOK_NUMBER, TOK_PLUS, TOK_MINUS, TOK_STAR, TOK_SLASH, TOK_LPAREN, TOK_RPAREN, TOK_SEMI, TOK_EOF, TOK_ERROR } TokenType; typedef struct { TokenType type; char value[64]; // 标识符/数字的字面值 int line; // 行号，报错用 } Token; // 主循环：跳过空白，按首字符分派 Token next_token(FILE *fp) { int ch; // 跳过空白和注释 while ((ch = fgetc(fp)) == ' ' || ch == '\n' || ch == '\t') { if (ch == '\n') line_no++; } if (ch == EOF) return make_token(TOK_EOF, "", line_no); if (isalpha(ch)) { // 标识符或关键字 return read_ident(fp, ch); } else if (isdigit(ch)) { // 数字 return read_number(fp, ch); } else { // 单字符符号 return read_symbol(ch); } }

这段代码的逻辑很直白：外层循环负责跳过空白、维护行号，内层按首字符分派到三个读取函数。read_ident会继续读字母数字直到非标识符字符，然后查关键字表决定是TOK_INT还是TOK_IDENT；read_number读连续数字；read_symbol处理单字符运算符和分隔符。参数上，line字段一定要维护好，后面语法和语义阶段报错全靠它定位。

这里有个容易忽略的点：read_ident读完后多读了一个字符（因为要判断标识符结束），这个字符必须“退回”输入流，否则下一个 token 会丢首字符。常见做法是用ungetc(ch, fp)。如果你发现 token 流里莫名其妙少字符，先查这里。

4.2 语法分析：递归下降与语法树节点

语法分析常见两种实现：递归下降和 LL(1) 预测分析表。实验包里递归下降更常见，因为代码直观、和文法对应关系清楚。核心是每个非终结符对应一个函数：

// 语法树节点，放在 common/ast.h typedef struct ASTNode { char *label; // 节点类型，如 "IfStmt"、"Assign" struct ASTNode **children; int child_count; Token token; // 关联的 token，保留行号 } ASTNode; // 表达式解析：加减法，左结合 ASTNode* parse_expr(Parser *p) { ASTNode *left = parse_term(p); // 先解析乘除层 while (peek(p).type == TOK_PLUS || peek(p).type == TOK_MINUS) { Token op = advance(p); ASTNode *right = parse_term(p); left = make_binary_node(op, left, right); // 构造二元节点 } return left; } // 项解析：乘除法，优先级高于加减 ASTNode* parse_term(Parser *p) { ASTNode *left = parse_factor(p); // 因子层：数字、标识符、括号 while (peek(p).type == TOK_STAR || peek(p).type == TOK_SLASH) { Token op = advance(p); ASTNode *right = parse_factor(p); left = make_binary_node(op, left, right); } return left; }

这段的关键是“分层”：parse_expr处理加减，parse_term处理乘除，parse_factor处理括号和原子。每层只关心自己这级的运算符，优先级自然就对了。peek看下一个 token 但不消费，advance消费并前进，这两个辅助函数是递归下降的标配。make_binary_node把运算符和左右子树组装成一个节点，label存节点类型，token存运算符位置用于报错。

参数上要注意Parser结构体里至少要有 token 数组、当前下标、错误计数。错误恢复策略常见做法是“panic mode”：遇到语法错误就跳到下一个分号或右括号，继续解析，这样一次能报多个错，而不是遇到第一个就退出。如果你手头的源码一遇错就exit(1)，二次开发时可以把这个改成错误计数 + 跳过，调试体验会好很多。

4.3 语义分析：符号表与类型检查

语义分析阶段的核心数据结构是符号表。常见做法是用哈希表或链表数组，按作用域分层：

// 符号表条目 typedef struct Symbol { char name[64]; char type[32]; // "int"、"float" 等 int scope_level; // 作用域层级 struct Symbol *next; // 同一作用域链表 } Symbol; // 作用域栈：进入块压栈，离开块弹栈 typedef struct Scope { Symbol *symbols; struct Scope *parent; } Scope; // 变量声明检查：同一作用域重复声明报错 int declare_symbol(Scope *cur, const char *name, const char *type) { Symbol *s = cur->symbols; while (s) { if (strcmp(s->name, name) == 0) { error("duplicate declaration: %s", name); return -1; } s = s->next; } // 插入新符号 Symbol *new_sym = malloc(sizeof(Symbol)); strcpy(new_sym->name, name); strcpy(new_sym->type, type); new_sym->scope_level = cur->parent ? cur->parent->symbols->scope_level + 1 : 0; new_sym->next = cur->symbols; cur->symbols = new_sym; return 0; }

这段代码展示了符号表最基础的两个操作：查重和插入。declare_symbol只在当前作用域查重，不查父作用域，这是对的——内层可以遮蔽外层同名变量。查找变量时则要从当前作用域一路往上找，直到根作用域。类型检查的常见做法是在语法树上做一次遍历，遇到赋值语句检查左右类型是否兼容，遇到函数调用检查实参个数和类型。

这里有个血泪经验：作用域层级scope_level的维护很容易出错。如果进入块时忘了压栈，或者离开块时忘了弹栈，符号表就会串层，表现为“内层变量在外层可见”或者“外层变量被误报重复声明”。排查方法是打印符号表快照，对照源码的{}嵌套看层级对不对。

5. 避坑与排查：五个真实翻车场景

5.1 现象：词法分析输出 token 数量比预期少

原因通常是标识符读取后没有正确回退多读的字符，或者注释处理逻辑把//后面的换行也吞了，导致下一行首个 token 丢失。解决方法是检查read_ident和注释跳过逻辑里的ungetc调用，并在每个 token 输出时打印行号，对照源码逐行核对。

5.2 现象：语法分析报“unexpected token”，但源码看起来没问题

先查 token 类型枚举和 parser 里peek的比较是否一致。常见翻车是词法阶段把关键字识别成了TOK_IDENT，parser 却按TOK_INT去匹配，自然对不上。排查手段是在 parser 入口把 token 流完整打印一遍，看关键字 token 的类型对不对。另一个常见原因是文法里漏了某个产生式，比如if语句没处理else分支。

5.3 现象：语义分析阶段符号表查不到已声明的变量

多半是作用域栈的压栈/弹栈时机不对。比如在解析函数体时提前弹了栈，或者块作用域的{}没有正确触发压栈。解决方法是给enter_scope和exit_scope加日志，打印当前层级和符号数量，对照源码的嵌套结构看哪一层少了。还有一种可能是变量声明语句本身没被语义分析遍历到，检查语法树遍历函数是否覆盖了所有节点类型。

5.4 现象：中间代码生成的四元式临时变量编号重复或跳号

临时变量计数器通常是全局或挂在生成器结构体上的。重复编号说明计数器被重置了（比如每个函数重新从 0 开始但没做作用域隔离），跳号说明某些分支生成了临时变量但没被使用。解决方法是把临时变量计数器做成单调递增，并在每个四元式输出时打印编号，人工扫一遍连续性。如果项目要求临时变量按函数隔离，就在进入函数时保存现场、退出时恢复。

5.5 现象：目标代码生成后，简单程序能跑，复杂表达式结果错误

这类问题多半出在寄存器分配或求值顺序上。教学型代码生成常见做法是用固定寄存器 + 栈保存中间结果，如果表达式嵌套深，栈操作顺序错了就会算错。排查方法是拿一个a = b + c * d这样的表达式，把生成的目标指令逐条手算一遍，对照四元式的求值顺序。另一个常见坑是函数调用时没保存调用者寄存器，导致返回后值被覆盖。

6. 二次开发：把实验包改造成你自己的编译器原型

6.1 先做接口固化，再动实现

二次开发最容易犯的错是一上来就改核心算法，改完发现上下游全崩了。我的建议是先做一件事：把每个阶段的输入输出接口用头文件或接口类固化下来，写一组回归测试用例，跑通基线。具体做法是给每个阶段定义清晰的run函数签名，输入输出都用 common 里的结构体，然后在test/下放一组覆盖典型语法（赋值、if、while、函数调用）的源文件，把当前输出存成expected/基线。

# 固化基线：每个测试用例跑一遍，保存输出 for f in test/full/*.c; do ./bin/compiler "$f" > "expected/$(basename $f).out" 2>&1 done # 改代码后回归对比 for f in test/full/*.c; do ./bin/compiler "$f" > /tmp/out.txt 2>&1 diff "expected/$(basename $f).out" /tmp/out.txt || echo "FAIL: $f" done

这套基线机制建立起来后，你改任何阶段都能立刻知道有没有破坏原有行为。这是我从多个实验包改造里总结出的最省事的手段，比事后 debug 划算得多。

6.2 三个可落地的改造方向

第一个方向是扩展语言特性。比如给文法加for循环、do-while、数组或结构体。改造顺序是：先改词法加关键字和符号，再改语法加产生式和 AST 节点，然后语义分析加类型规则，最后中间代码和目标代码加对应生成逻辑。每加一个特性就跑一遍基线，确保老用例不回归。

第二个方向是替换某个阶段的实现。比如把递归下降换成 LL(1) 预测分析表，或者把四元式换成三地址码的另一种表示。这种改造的关键是保持接口不变，内部随便换。我一般会保留旧实现作为legacy/分支，新实现通过编译开关切换，方便对比。

第三个方向是加可视化输出。把语法树导出成 DOT 格式，用 Graphviz 渲染成图；把符号表按作用域层级打印成缩进结构；把四元式序列导出成表格。这些可视化对调试和演示都有用，而且改动集中在输出层，风险低。

6.3 一个具体技巧：用中间产物做“断点”

编译器调试最难受的是“结果错了但不知道哪一步错的”。我的习惯是在每个阶段结束时把中间产物落盘：token 流存.tok，语法树存.ast，符号表存.sym，四元式存.ir。这样出错时不用重跑整个流程，直接看对应文件就能定位。实现上就是在各阶段run函数末尾加一个dump_to_file调用，用环境变量控制开关，比如DUMP_STAGE=ir ./bin/compiler sample.c。

这个技巧配合基线对比，基本能做到“改一处、验一处”。从那以后我每次动编译器代码，都强制先跑一遍基线回归，再看中间产物 dump，确认数据流每一段都对得上才继续往下改。希望这套拆解能帮到你，把这份实验包真正跑起来、改下去。

本文还有配套的精品资源，点击获取