简介面向重庆大学等高校编译原理课程学习者的完整实验代码仓库覆盖词法分析、语法分析、语义分析、中间代码生成与目标代码优化并针对PL0教学语言实现可运行的编译器。压缩包共44个文件体积约1.83MB其中cpp/c/h源码展示编译各阶段实现docx提供实验报告模板txt/xml/cmake等包含构建配置与学习说明exe便于直接查看运行效果此外还有pptm演示文稿、md笔记等辅助材料。已有63人学习下载适合正在完成编译实验或准备期末项目的学生。整体目录结构清晰从源码、报告模板到学习笔记均有收录不仅帮助读者理解源代码到目标代码的转换流程也为实验报告撰写和程序调试提供具体示范。对PL0编译器的实现细节、词法分析的状态机设计以及符号表管理等关键环节都能在代码与笔记中找到直接参考。1. 编译原理课程实验资源包为什么一门课的重难点被压进一个zip编译原理实验周很多人第一晚就砸在词法分析器上——不是状态转换图难画而是代码一跑就崩崩了还不知道从哪儿查起。这套以 PL0 语言为靶子的编译原理课程实验资源整合代码仓库加实验报告模板加学习笔记把编译器的完整链路拆成了五个段词法分析器、语法分析器、语义分析、中间代码生成、目标代码优化让课程实验从“背上一届的代码”变成“照着模块边界自己复现一遍”。适合正在做编译原理实验的学生也适合想入门编译器开发、但不想一上来就啃 GCC 源码的工程师。PL0 规模小但五脏俱全跑通这条链你才算真的见过编译器长什么样。2. 从词法分析到目标代码优化一个PL0编译器六个实验模块的依赖链2.1 PL0语言为什么能当编译原理实验的靶子PL0 语言是 Pascal 的一个精简子集由 Pascal 之父 Niklaus Wirth 在《Algorithms Data Structures Programs》里提出。它只保留整型变量、过程嵌套、IF/THEN、WHILE/DO、CALL 这类最小要素却完整覆盖了编译器的关键环节词法分析、语法分析、语义分析、中间代码生成、目标代码生成与优化。正因为规模小一个完整可运行的 PL0 编译器通常只需要几千行代码一个学期按实验推进每个实验正好对应一个模块所以国内高校的编译原理课普遍拿它当实验靶子重庆大学的课程实验也不例外。写 PL0 时大家常说的“编译器开发”这个宏大的词落到课程实验里就是五件具体的事写一个把源文件切成 token 的词法分析器写一个判断 token 组合是否符合文法的语法分析器在语法分析过程中维护符号表并完成语义检查把语法结构翻译成四元式这样的中间代码最后在中间代码上做常量折叠和死代码删除这类目标代码优化。这五件事不是平行的而是严格的流水线依赖前一级的产出是后一级的输入前端任何一层出错后端全部没法跑。这也是这门课实验最容易让人半夜对着黑匣子发愁的原因——错误可能出现在任何一层你得沿着依赖链一层层往回找。很多教材还会给 PL0 配上 P-code 解释器作为后端让生成的目标代码直接在一个栈式虚拟机里执行。这样实验链路变成PL0 源程序 → 词法分析器产出 token 流 → 语法分析器生成抽象语法结构或递归下降调用序列→ 语义检查后的符号表 → P-code → 解释执行结果。不管你的课程最后采用哪种中间表达我建议先把这条链刻在脑子里后面所有排错都在回答同一个问题眼前这个现象是链条上的哪一环造成的词法分析器到语法分析器之间只用 token 流通信这种解耦也是真实编译器项目的工程底线——你以后换一种词法实现语法分析器一行都不用改。2.2 词法分析器与语法分析器的唯一接口token流词法分析器的产出是一个 token 流每个 token 至少带三样东西类型、字面值、行号。类型决定语法分析器怎么归类字面值保留原始文本行号是报错时唯一的定位线索。很多同学刚上手时会混淆编辑器和编译器的职责编辑器做的是把源码文本存成文件编译器才从文件读字符流开始做词法分析你写的第一个词法分析器本质上就是手动实现“从字符流到 token 流”的转换这也是实验里第一次感受到“编译”和“编辑”完全不同的地方。正则表达式到 NFA/DFA 的整套理论在课程实验里往往并不直接落地为自动机驱动代码。因为手写一个 DFA 状态表并维护当前状态的转发对 PL0 这么小的语言来说工程成本偏高绝大多数能跑通的实验写法是把状态转换图先画在草稿纸上然后用循环加 switch 按当前字符类型判断下一个状态。这不叫偷懒工程上叫为确定的问题选最便宜的实现。只有当你面对的是完整 Pascal 或 C 语言那种体量才值得上 flex 这样的自动生成器。词法分析和语法分析之间的契约是实验中第一个要锁死的接口。我见过太多人在 parser 里直接访问全局 token 变量导致词法多读了一个字符、语法分析整段错位。最稳的做法是定义 token 结构体用 next_token() 函数产出 token语法分析器只通过这个函数推进输入词法分析器也只对你暴露这个函数。这样单元测试时可以把 token 流单独打出来比对联调时也能明确出错在哪一侧。词法分析阶段还要处理错误恢复遇到无法识别的字符记录行号并报错而不是静默跳过否则语法分析器拿到的错误定位全是错的。2.3 语义分析、中间代码生成、目标代码优化一条链上的三个分段语义分析和中间代码生成在课程实验里往往是伴着语法分析一起做的也就是语法制导翻译语法分析器每归约出一个产生式就顺手查一次符号表、发出一条四元式。这就要求符号表的实现足够干净否则语义分析会被语法分析拖着一起崩。PL0 的语义检查点不多但每一条都要有准确报错未声明变量、重复声明、把常量当变量赋值、过程调用参数个数不匹配。PL0 没有数组和记录类型符号表的压力主要来自嵌套过程。每个过程有自己的作用域内部声明覆盖外层同名符号过程结束要恢复。经典实现是符号表项带一个作用域序号按栈组织查找时从当前过程符号表往回摸插入只在当前作用域进行退出过程时把整个作用域链断掉。这里的原则是进了作用域就压栈退了就弹如果你省掉这一步嵌套过程里同名变量查错就是必然。四元式是课程实验里最常见的中间代码形态一条四元式是 op、arg1、arg2、result 四个字段。PL0 的所有赋值和运算都能映射上去a : b c 翻译成 ADD b c aIF a b 翻译成 LT a b 后面挂跳转。临时变量从 t1 开始编号这个编号是中间代码生成阶段的隐性全局变量也是最容易翻车的地方。目标代码优化在课程实验里能做的其实有限常做的是常量折叠把 CONST 定义和字面量的纯常量运算在编译期算掉、死代码删除删掉 IF 条件恒假的 THEN 分支、以及跳转冗余消除。寄存器分配、循环不变量外提这类优化已经越过课程边界硬做只会引入更多不确定因素。你要记住一个原则优化必须保持可观测行为不变所以实验里每做一步优化都要有优化前后的中间代码对比作为报告素材这也是“编译器优化”这个词在课程里真正的呈现方式——不是追求生成代码多快而是证明你的变换是对的。3. 把PL0编译器在本地跑通工程目录、DFA词法分析与递归下降语法分析代码3.1 实验代码仓库的目录划分前端、后端、测试与文档分开拿到或整理这套编译原理实验项目代码时第一件事不是读代码是看目录。一个能长期复用、期末能拿来交实验报告的仓库应该把前端、后端、测试、文档四个域切开。常见的组织结构是三层目录加一个测试区pl0-compiler/ ├── include/ # 头文件token.h、symbol.h、quad.h ├── src/ # 源文件lexer.c、parser.c、semantic.c、codegen.c、main.c ├── test/ # 测试用例*.pl0 源程序 run_tests.sh 冒烟脚本 ├── docs/ # 实验报告模板和学习笔记的 Markdown 源文件 ├── Makefile # 一键编译 └── README.md # 模块边界与编译方式把词法分析器、语法分析器、语义分析、中间代码生成的代码全塞进一个文件期末联调时你会恨不得有后悔药——哪怕只是一个符号表查找函数写错都要在几百行里翻找。按模块分文件每个文件只暴露头文件里的三五个函数出错时才能快速定位是哪一层的问题。如果实验代码用的是 C 或 Java模块边界保持不变只是把结构体换成 class、把函数指针换成虚方法学习成本并不高。链接阶段的坑也藏在这个目录里如果 main 函数被放在词法分析器文件里而你在 Makefile 里又把 lexer.o 和 main.o 一起链接十有八九会遇到重复定义或者找不到入口。常见做法是单独建 main.c它只负责打开源文件、循环调用 next_token、调用 parse_program、调用 codegen、调用 optimize。控制流在 main 里模块之间不互相越权调用这个结构也方便后面做第六个模块、也就是整体联调时的冒烟测试。Makefile 里关于标准版本也要写清楚我一般会在编译参数里固定-stdc99 -Wall避免不同环境默认标准不一样导致同一份代码行为不同。下面是词法分析器和语法分析器的最小可运行代码示例。3.2 词法分析器最小实现一张DFA状态表加一个next_token词法分析器我一般用“主循环加字符分类”的方式写不引入自动生成器。先定义 token 枚举和结构体typedef enum { TK_IDENT, TK_NUMBER, TK_BEGIN, TK_END, TK_IF, TK_THEN, TK_WHILE, TK_DO, TK_CALL, TK_CONST, TK_VAR, TK_PROCEDURE, TK_ODD, TK_PLUS, TK_MINUS, TK_TIMES, TK_DIVIDE, TK_EQUAL, TK_NEQ, TK_LT, TK_LE, TK_GT, TK_GE, TK_ASSIGN, TK_LPAREN, TK_RPAREN, TK_COMMA, TK_SEMICOLON, TK_PERIOD, TK_EOF } TokenType; typedef struct { TokenType type; char text[64]; int value; /* 仅 TK_NUMBER 时有效 */ int line; /* 行号报错和实验报告里的定位都靠它 */ } Token;关键点在于 token 携带 line 字段后面语义分析和报告排错全依赖它type 枚举的顺序没有硬性要求但建议把关键字放在枚举靠前的位置方便识别关键字时按枚举区间查表。下一个 token 的识别逻辑Token next_token(SourceFile *src) { Token tok {0}; int c; while ((c src_peek(src)) || c \t || c \n || c \r) { if (c \n) src-line; src_next(src); } if (src_eof(src)) { tok.type TK_EOF; return tok; } c src_peek(src); tok.line src-line; if (isalpha(c)) { /* 标识符或关键字 */ int i 0; while (isalnum(src_peek(src))) { tok.text[i] (char)src_next(src); } tok.text[i] \0; tok.type keyword_type(tok.text, TK_IDENT); return tok; } if (isdigit(c)) { /* 数字常量 */ int v 0; while (isdigit(src_peek(src))) { v v * 10 (src_next(src) - 0); } tok.type TK_NUMBER; tok.value v; snprintf(tok.text, sizeof(tok.text), %d, v); return tok; } tok.type operator_type(src, c); /* 多字符运算符: */ if (tok.type ! TK_ERROR) { src_next(src); /* 吃掉第二个字符 */ return tok; } tok.type one_char_operator(c); src_next(src); return tok; }这里的空白处理看似简单其实是血泪重灾区如果你漏掉对 \r 的处理在 Windows 下用 CRLF 换行的源文件会让行号全部错位实验报告里的截图对不上代码行号老师会直接质疑测试真实性。keyword_type 用二分查找或哈希都可以PL0 只有十几个关键字线性查表也够快但一定要把它做成独立函数方便单独测试。注意多字符运算符的识别顺序要先于单字符运算符。比如读到了 :必须先看下一个字符是不是 是就要读成赋值号否则 : 在这个语言里根本没有定义。顺序写反的话a : b 会被切成 : 和 两个 token语法分析器永远等不到它想要的赋值号。遇到无法识别的字符正确的做法是返回 TK_ERROR 并记录行号让上层报“第 n 行有非法字符”而不是静默跳过——很多同学在这里选择忽略结果后面语法分析因为缺了一个 token 而报出完全错位的错误位置。3.3 递归下降语法分析代码从EBNF到C函数的机械映射PL0 的算术表达式文法只有三个层次expression、term、factor正好对应加减、乘除、原子三个优先级。写成 EBNF 是expression :: [|-] term { (|-) term } term :: factor { (*|/) factor } factor :: NUMBER | IDENT | ( expression )这个文法没有左递归可以直接映射成递归下降函数。优先级是靠函数调用层级表达的expression 调 termterm 调 factor越底层优先级越高这是递归下降的核心机制学名叫优先级分层。int parse_expression(Parser *p) { if (p-tok.type TK_PLUS || p-tok.type TK_MINUS) { consume(p); /* 一元正负号 */ } parse_term(p); while (p-tok.type TK_PLUS || p-tok.type TK_MINUS) { consume(p); parse_term(p); } return 0; } int parse_term(Parser *p) { parse_factor(p); while (p-tok.type TK_TIMES || p-tok.type TK_DIVIDE) { consume(p); parse_factor(p); } return 0; } int parse_factor(Parser *p) { if (p-tok.type TK_NUMBER) { consume(p); return 0; } if (p-tok.type TK_IDENT) { consume(p); return 0; } if (p-tok.type TK_LPAREN) { consume(p); parse_expression(p); expect(p, TK_RPAREN); return 0; } error(p, factor: 期望 NUMBER、IDENT 或 (); return -1; }这段代码看起来短但里面有一个初学者都会踩的坑parse_term 调 parse_factor 时没有保存任何语义信息等后面加四元式生成时你会发现表达式树的左操作数无处存放。所以正式的实验代码里这些函数通常返回一个“地址描述符”结构体或者把子表达式结果存进 AST 结点。这也是语法分析器和生命周期语义分析天然耦合的原因——你在递归下降的同时就得决定每个非终结符的语义返回值等后面再回头改等于把语法分析器重写一遍。语法分析器测试时我建议单独做一个 dump 模式把每次 consume 的 token 按先后序列打印出来再和词法分析器的 token 流对比。只要这两条序列对得上语法分析端的定位错误就排除了大半。4. 中间代码生成、目标代码优化与实验报告模板三个需要提前准备的模块4.1 四元式生成与临时变量编号中间代码的三个必调参数四元式是 op、arg1、arg2、result 四个字段的数组结构PL0 的运算和跳转都能塞进去。常见做法是维护一个 Quad 数组和 next_quad 游标每归约出一个产生式就 emit 一条。这里有一个从开头就要锁死的约定临时变量从 t1 开始递增编号不要重复使用不要回收。typedef struct { int op; /* OP_PLUS, OP_MINUS, OP_TIMES, OP_DIVIDE, OP_LT, OP_JMP, OP_JZ */ int arg1; int arg2; int result; /* 变量索引或临时变量编号 t1, t2 ... */ } Quad; int temp_counter; Quad quads[1024]; int next_quad; int new_temp(void) { return -(temp_counter); /* 用负数表示临时变量符号表索引为正数 */ } void emit_quad(int op, int arg1, int arg2, int result) { if (next_quad 1024) { fprintf(stderr, 四元式表溢出实验程序已超过预期规模\n); exit(1); } quads[next_quad].op op; quads[next_quad].arg1 arg1; quads[next_quad].arg2 arg2; quads[next_quad].result result; next_quad; }new_temp 里用负数区分临时变量和符号表索引是一个很小的约定但能让代码生成阶段少写一半判断逻辑。四元式表固定 1024 上限在课程实验里远够用用数组而不是动态链表是为了让打印中间代码时顺序稳定实验报告里贴出的四元式编号不会因为内存分配变化而闪烁。arg1 和 arg2 对运算符四元式是操作数对跳转四元式 JMP/JZarg1 放的是跳转目标四元式编号等回填时再改。回填是中间代码生成里最容易黑匣子化的环节。处理 IF 和 WHILE 时你往往先发一条跳转四元式此时目标四元式还没生成只能先填一个占位值等条件分支语句体遍历完再回头改。这个占位值要单独记在一个变量里否则两个嵌套 IF 的跳转目标会互相覆盖。我会在 Parser 的语义动作里用一个 int 数组保存待回填的四元式下标每层条件嵌套入栈、退出出栈规则和符号表作用域一模一样。4.2 目标代码优化做到哪一层常量折叠、死代码删除的边界目标代码优化在课程实验里是最容易被做坏的部分。一个常见误区是引入大段寄存器分配和活跃变量分析算法结果优化器比编译器本体还复杂老师又不敢确定是不是你自己写的。课程定位的实验优化做到常量折叠、死代码删除和跳转消除就够了关键是要留下操作日志让每一步优化有据可查。优化手段做什么风险报告验证方式常量折叠把 CONST 定义和字面量的纯常量运算在编译期算掉改变除法取整语义优化前后四元式对比死代码删除删除 x : x 这类自赋值和恒假分支误删有副作用的 CALL 语句给一个含 CALL 的测试用例跳转消除把 JMP 到紧接着的下一条指令消掉与回填顺序耦合打印优化后的跳转序列死代码删除里最典型的问题在上面表格里也提到了PL0 的过程调用也有观测副作用只做数据依赖分析会误删 CALL。课程实验里我建议只对“赋值语句和算术四元式”做死代码删除过程调用一律视为活跃。这个边界意识比优化算法本身重要——你交上去的报告里如果写了这一条老师就知道你是真的踩过坑而不是在背概念。优化器的输入输出要保持“中间代码到中间代码”输出之后再 dump 一份四元式文件。这样优化器和代码生成器不耦合重跑一遍编译就能对比优化前后的两条四元式序列实验报告里的对比截图也就是这么来的。4.3 实验报告模板与学习笔记老师评分时读的不只是代码实验报告模板在资源整合里的作用常被低估。太多课程报告只贴源代码和最终截图缺少“这个实验我改了什么、遇到什么问题、怎么验证的”。一份能拿得出手的实验报告模板按这个结构组织实验目的与文法说明、模块设计与接口定义、关键代码与数据结构、测试用例与运行结果、问题踩坑与解决过程、附录完整代码路径。其中测试用例与运行结果是最有区分度的部分。测试用例要给出三种输入合法的完整 PL0 程序、边界条件下的合法程序空语句过程体、嵌套过程同名变量、故意写错的程序缺分号、括号不匹配、未声明变量。对每一种输入贴运行日志日志里要有解析到的行号。老师评分时读的是“这组测试能否证明你的模块边界是对的”而不是代码排版好不好看。记得把测试用例 .pl0 文件和对应输出一起归档报告里贴日志时标注输入文件路径让老师能一键复现。学习笔记的组织方式我建议按“一个实验模块一节”每节只记三样东西文法或状态转换图的推导过程、调试中真正踩过的报错原因、与教材默认实现的差异。比如 FIRST/FOLLOW 集合和递归下降的对应关系、四元式 op 码表为什么要这样设计都属于值得记的。把这些笔记整理进 docs 目录期末复习时你会感谢当时肯写笔记的自己。这里有经验笔记里一定要写“我原以为会怎样实际是怎样”这种反差记录才真正帮助理解只是抄讲义重点的话期末不会翻。5. 编译原理实验避坑指南从环境配置到验收的五个高频问题5.1 编译器报“未包含main类型”入口函数迷路的真相现象gcc 编译链接后报 ld 返回 1 exit status提示 undefined reference to main有的 IDE 会翻译成一句神秘的“编译器未包含 main 类型”。原因一种情况是 main.c 忘记写进 Makefile 的源文件列表另一种更隐蔽——词法分析器文件里定义了一个叫 main 的测试函数真正的入口在 parser.c 里两个 main 撞车还有一种是用了 MSVC 的旧项目模板入口函数被设置成了别的名字或者 main 返回值写了 void在 gcc 默认标准下直接不让编。解决单独维护 main.cMakefile 里把源文件列表写成OBJ lexer.o parser.o main.o这种变量链接时把 main.o 放最前面gcc 的链接顺序会影响符号解析。再加-Wall -Werrormain这类参数入口问题在编译阶段就暴露不用等到链接。每次换机器编译时第一件事是make clean再全量重编很多“昨天能跑今天不能”的玄学问题就是因为增量编译拿了旧的目标文件。5.2 二义性文法导致解析结果错乱悬垂else与优先级现象if a then if b then x : 1 else x : 2被解析成了if a then (if b then x : 1 else x : 2)和教材预期相反程序行为也完全不对。原因PL0 的 IF 和 ELSE 配对规则如果写成二义文法递归下降会按照就近匹配直接给出行为关键是你自己未必意识到这个行为已经嵌进了代码。算术表达式也一样如果 expression 没有分层a b * c 会被解析成 (a b) * c。解决把文法的 EBNF 先写清楚再写代码。算术表达式必须拆成 expression/term/factor 三层IF 语句的配对问题一种做法是规定 ELSE 必须和最内层未配对的 IF 匹配另一种是干脆在文法里禁止裸 IF 嵌套要求写IF ... THEN BEGIN ... END ELSE BEGIN ... END。写完 Parser 后用几个刁钻用例验证优先级不要只看正确路径这类问题在词法分析和语法分析联调的第二天集中爆发。5.3 符号表作用域不处理嵌套过程里同名变量的幽灵现象内层过程声明了和外层同名的变量编译时查到的始终是外层的值或者过程结束后符号表里还残留内层声明外层同名变量被污染。原因符号表没有按作用域链做压栈弹栈。常见实现错误是用一个扁平数组存符号插入时只做线性查找根本没有“当前过程是哪个”的概念。解决符号表项加 ScopeLevel 字段查找时从当前层往下找到最内层匹配项过程结束时把该层所有符号标记为不可见或整体弹出。PL0 只有嵌套过程这个链不会很复杂压栈弹栈逻辑用独立函数实现别散落在 semantic.c 各处。我自己的习惯是每次过程结束时导出一份当前符号表快照对比一下内层声明是否真的消失了这一步能把很多隐蔽错误挡在联调之前。5.4 gcc与MSVC行为差异同一份C代码两边结果不一样现象在教室用 MSVC 编译通过的实验代码拿回 Linux 用 gcc 编译直接报错最常见的报错位置是 for 循环里声明int iMSVC 的旧标准不支持这种写法。原因MSVC 对 C89/C99 的处理和 gcc 不一样老课程参考代码多半是 C89 风格变量声明必须在块开头。而 gcc 默认还可能按 GNU17 这类标准编译两边一迁移就暴露差异。解决在项目说明和 Makefile 里写死标准版本。gcc 加-stdc99 -WallMSVC 把 .c 文件改成 .cpp 后用 C 编译器编是一条省心路径或者干脆统一写成 C89 风格所有变量声明放到函数顶部。平台差异不属于算法难度纯属工程约定但每年都有小组卡在这里两三天而且这种问题你自己查不出来时很难在搜索里找到关键词。5.5 实验报告只有代码没有运行验证验收时被追问的第一现场现象报告里贴了完整源码和几张截图老师一追问“这个用例的输出为什么是这个数值”当场回答不上来。原因没有保留测试的输入文件和运行日志截图来源连自己也说不清。有的同学会临时跑一个用例补截图但那张图的路径在报告里根本对不上。解决把测试用例 .pl0 文件和对应的运行输出一起归档到 test 目录报告贴日志时标注“输入文件 test/if_else.pl0输出见下”让老师能复现。这也顺带解决一个信任问题凡是能一键重跑的实验评分争议都少得多。报告里还要加上这段日志是第几次编译生成的、用的哪个 Makefile 目标这些细节在验收时都是“这实验是自己做的”的有力证据。6. 把PL0实验环境变成可复用资产冒烟测试脚本与进阶验证方向6.1 冒烟测试脚本让五个模块一键回归到这一步代码已经能编译运行但你要让它能长期复用得写一个冒烟测试脚本跑一遍全流程。常见做法是把合法用例、非法用例、含优化前后对比的用例都放进 test 目录脚本逐个编译执行、对比退出码和中间代码输出#!/bin/bash # run_tests.sh —— 编译原理实验冒烟测试 PASS0 FAIL0 mkdir -p out for src in test/case_*.pl0; do name$(basename $src .pl0) ./pl0c $src out/${name}.ir 2 out/${name}.err if [ $? -eq 0 ] [ -s out/${name}.ir ]; then PASS$((PASS1)) echo [PASS] $name else FAIL$((FAIL1)) echo [FAIL] $name —— 见 out/${name}.err 第 1 行 fi done echo PASS$PASS FAIL$FAIL exit $FAIL这个脚本的价值在你改动符号表或者优化器之后立刻体现跑一遍哪几个用例挂掉错误文件里第一行就是定位线索。课程实验的五个模块层层堆叠改了中间代码生成如果无意间碰了语法分析那边脚本会立刻抓住回归。这也就是“代码仓库”和“抄来的代码”之间的分水岭——前者敢随时重新构建后者不敢。6.2 从课程实验到真实编译器下一步学什么跑通 PL0 这条链之后你其实已经掌握了一条通用的设计线前端按 token、语法结构拆解后端按中间表达和优化分层。下一步可以做的方向是把递归下降换成 flex/bison 自动生成器把四元式的解释执行换成真实指令选择把符号表从单整型扩展到带类型系统。每个方向都能单独成实验但原理都被压缩在这门课里只是规模和工程复杂度上了一个台阶。我自己的教训是当年急着把语法分析器写得“高级”引入了一堆抽象层级最后联调时错误被层层包装排错时间比写代码时间还长。后来养成的习惯是任何改动先跑一遍冒烟脚本再抓具体用例调试宁可慢一点也不要开着黑匣子瞎试。如果你也在做编译原理实验希望这套拆法能帮到你先保证依赖链清晰再追求优化与算法交付的不只是一份报告而是一个能反复重跑、敢让老师当面点下运行键的实验环境。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 4:58:52 · 阅读 1.2k PL0编译器实验全解析：从词法分析到目标代码优化
简介面向重庆大学等高校编译原理课程学习者的完整实验代码仓库覆盖词法分析、语法分析、语义分析、中间代码生成与目标代码优化并针对PL0教学语言实现可运行的编译器。压缩包共44个文件体积约1.83MB其中cpp/c/h源码展示编译各阶段实现docx提供实验报告模板txt/xml/cmake等包含构建配置与学习说明exe便于直接查看运行效果此外还有pptm演示文稿、md笔记等辅助材料。已有63人学习下载适合正在完成编译实验或准备期末项目的学生。整体目录结构清晰从源码、报告模板到学习笔记均有收录不仅帮助读者理解源代码到目标代码的转换流程也为实验报告撰写和程序调试提供具体示范。对PL0编译器的实现细节、词法分析的状态机设计以及符号表管理等关键环节都能在代码与笔记中找到直接参考。1. 编译原理课程实验资源包为什么一门课的重难点被压进一个zip编译原理实验周很多人第一晚就砸在词法分析器上——不是状态转换图难画而是代码一跑就崩崩了还不知道从哪儿查起。这套以 PL0 语言为靶子的编译原理课程实验资源整合代码仓库加实验报告模板加学习笔记把编译器的完整链路拆成了五个段词法分析器、语法分析器、语义分析、中间代码生成、目标代码优化让课程实验从“背上一届的代码”变成“照着模块边界自己复现一遍”。适合正在做编译原理实验的学生也适合想入门编译器开发、但不想一上来就啃 GCC 源码的工程师。PL0 规模小但五脏俱全跑通这条链你才算真的见过编译器长什么样。2. 从词法分析到目标代码优化一个PL0编译器六个实验模块的依赖链2.1 PL0语言为什么能当编译原理实验的靶子PL0 语言是 Pascal 的一个精简子集由 Pascal 之父 Niklaus Wirth 在《Algorithms Data Structures Programs》里提出。它只保留整型变量、过程嵌套、IF/THEN、WHILE/DO、CALL 这类最小要素却完整覆盖了编译器的关键环节词法分析、语法分析、语义分析、中间代码生成、目标代码生成与优化。正因为规模小一个完整可运行的 PL0 编译器通常只需要几千行代码一个学期按实验推进每个实验正好对应一个模块所以国内高校的编译原理课普遍拿它当实验靶子重庆大学的课程实验也不例外。写 PL0 时大家常说的“编译器开发”这个宏大的词落到课程实验里就是五件具体的事写一个把源文件切成 token 的词法分析器写一个判断 token 组合是否符合文法的语法分析器在语法分析过程中维护符号表并完成语义检查把语法结构翻译成四元式这样的中间代码最后在中间代码上做常量折叠和死代码删除这类目标代码优化。这五件事不是平行的而是严格的流水线依赖前一级的产出是后一级的输入前端任何一层出错后端全部没法跑。这也是这门课实验最容易让人半夜对着黑匣子发愁的原因——错误可能出现在任何一层你得沿着依赖链一层层往回找。很多教材还会给 PL0 配上 P-code 解释器作为后端让生成的目标代码直接在一个栈式虚拟机里执行。这样实验链路变成PL0 源程序 → 词法分析器产出 token 流 → 语法分析器生成抽象语法结构或递归下降调用序列→ 语义检查后的符号表 → P-code → 解释执行结果。不管你的课程最后采用哪种中间表达我建议先把这条链刻在脑子里后面所有排错都在回答同一个问题眼前这个现象是链条上的哪一环造成的词法分析器到语法分析器之间只用 token 流通信这种解耦也是真实编译器项目的工程底线——你以后换一种词法实现语法分析器一行都不用改。2.2 词法分析器与语法分析器的唯一接口token流词法分析器的产出是一个 token 流每个 token 至少带三样东西类型、字面值、行号。类型决定语法分析器怎么归类字面值保留原始文本行号是报错时唯一的定位线索。很多同学刚上手时会混淆编辑器和编译器的职责编辑器做的是把源码文本存成文件编译器才从文件读字符流开始做词法分析你写的第一个词法分析器本质上就是手动实现“从字符流到 token 流”的转换这也是实验里第一次感受到“编译”和“编辑”完全不同的地方。正则表达式到 NFA/DFA 的整套理论在课程实验里往往并不直接落地为自动机驱动代码。因为手写一个 DFA 状态表并维护当前状态的转发对 PL0 这么小的语言来说工程成本偏高绝大多数能跑通的实验写法是把状态转换图先画在草稿纸上然后用循环加 switch 按当前字符类型判断下一个状态。这不叫偷懒工程上叫为确定的问题选最便宜的实现。只有当你面对的是完整 Pascal 或 C 语言那种体量才值得上 flex 这样的自动生成器。词法分析和语法分析之间的契约是实验中第一个要锁死的接口。我见过太多人在 parser 里直接访问全局 token 变量导致词法多读了一个字符、语法分析整段错位。最稳的做法是定义 token 结构体用 next_token() 函数产出 token语法分析器只通过这个函数推进输入词法分析器也只对你暴露这个函数。这样单元测试时可以把 token 流单独打出来比对联调时也能明确出错在哪一侧。词法分析阶段还要处理错误恢复遇到无法识别的字符记录行号并报错而不是静默跳过否则语法分析器拿到的错误定位全是错的。2.3 语义分析、中间代码生成、目标代码优化一条链上的三个分段语义分析和中间代码生成在课程实验里往往是伴着语法分析一起做的也就是语法制导翻译语法分析器每归约出一个产生式就顺手查一次符号表、发出一条四元式。这就要求符号表的实现足够干净否则语义分析会被语法分析拖着一起崩。PL0 的语义检查点不多但每一条都要有准确报错未声明变量、重复声明、把常量当变量赋值、过程调用参数个数不匹配。PL0 没有数组和记录类型符号表的压力主要来自嵌套过程。每个过程有自己的作用域内部声明覆盖外层同名符号过程结束要恢复。经典实现是符号表项带一个作用域序号按栈组织查找时从当前过程符号表往回摸插入只在当前作用域进行退出过程时把整个作用域链断掉。这里的原则是进了作用域就压栈退了就弹如果你省掉这一步嵌套过程里同名变量查错就是必然。四元式是课程实验里最常见的中间代码形态一条四元式是 op、arg1、arg2、result 四个字段。PL0 的所有赋值和运算都能映射上去a : b c 翻译成 ADD b c aIF a b 翻译成 LT a b 后面挂跳转。临时变量从 t1 开始编号这个编号是中间代码生成阶段的隐性全局变量也是最容易翻车的地方。目标代码优化在课程实验里能做的其实有限常做的是常量折叠把 CONST 定义和字面量的纯常量运算在编译期算掉、死代码删除删掉 IF 条件恒假的 THEN 分支、以及跳转冗余消除。寄存器分配、循环不变量外提这类优化已经越过课程边界硬做只会引入更多不确定因素。你要记住一个原则优化必须保持可观测行为不变所以实验里每做一步优化都要有优化前后的中间代码对比作为报告素材这也是“编译器优化”这个词在课程里真正的呈现方式——不是追求生成代码多快而是证明你的变换是对的。3. 把PL0编译器在本地跑通工程目录、DFA词法分析与递归下降语法分析代码3.1 实验代码仓库的目录划分前端、后端、测试与文档分开拿到或整理这套编译原理实验项目代码时第一件事不是读代码是看目录。一个能长期复用、期末能拿来交实验报告的仓库应该把前端、后端、测试、文档四个域切开。常见的组织结构是三层目录加一个测试区pl0-compiler/ ├── include/ # 头文件token.h、symbol.h、quad.h ├── src/ # 源文件lexer.c、parser.c、semantic.c、codegen.c、main.c ├── test/ # 测试用例*.pl0 源程序 run_tests.sh 冒烟脚本 ├── docs/ # 实验报告模板和学习笔记的 Markdown 源文件 ├── Makefile # 一键编译 └── README.md # 模块边界与编译方式把词法分析器、语法分析器、语义分析、中间代码生成的代码全塞进一个文件期末联调时你会恨不得有后悔药——哪怕只是一个符号表查找函数写错都要在几百行里翻找。按模块分文件每个文件只暴露头文件里的三五个函数出错时才能快速定位是哪一层的问题。如果实验代码用的是 C 或 Java模块边界保持不变只是把结构体换成 class、把函数指针换成虚方法学习成本并不高。链接阶段的坑也藏在这个目录里如果 main 函数被放在词法分析器文件里而你在 Makefile 里又把 lexer.o 和 main.o 一起链接十有八九会遇到重复定义或者找不到入口。常见做法是单独建 main.c它只负责打开源文件、循环调用 next_token、调用 parse_program、调用 codegen、调用 optimize。控制流在 main 里模块之间不互相越权调用这个结构也方便后面做第六个模块、也就是整体联调时的冒烟测试。Makefile 里关于标准版本也要写清楚我一般会在编译参数里固定-stdc99 -Wall避免不同环境默认标准不一样导致同一份代码行为不同。下面是词法分析器和语法分析器的最小可运行代码示例。3.2 词法分析器最小实现一张DFA状态表加一个next_token词法分析器我一般用“主循环加字符分类”的方式写不引入自动生成器。先定义 token 枚举和结构体typedef enum { TK_IDENT, TK_NUMBER, TK_BEGIN, TK_END, TK_IF, TK_THEN, TK_WHILE, TK_DO, TK_CALL, TK_CONST, TK_VAR, TK_PROCEDURE, TK_ODD, TK_PLUS, TK_MINUS, TK_TIMES, TK_DIVIDE, TK_EQUAL, TK_NEQ, TK_LT, TK_LE, TK_GT, TK_GE, TK_ASSIGN, TK_LPAREN, TK_RPAREN, TK_COMMA, TK_SEMICOLON, TK_PERIOD, TK_EOF } TokenType; typedef struct { TokenType type; char text[64]; int value; /* 仅 TK_NUMBER 时有效 */ int line; /* 行号报错和实验报告里的定位都靠它 */ } Token;关键点在于 token 携带 line 字段后面语义分析和报告排错全依赖它type 枚举的顺序没有硬性要求但建议把关键字放在枚举靠前的位置方便识别关键字时按枚举区间查表。下一个 token 的识别逻辑Token next_token(SourceFile *src) { Token tok {0}; int c; while ((c src_peek(src)) || c \t || c \n || c \r) { if (c \n) src-line; src_next(src); } if (src_eof(src)) { tok.type TK_EOF; return tok; } c src_peek(src); tok.line src-line; if (isalpha(c)) { /* 标识符或关键字 */ int i 0; while (isalnum(src_peek(src))) { tok.text[i] (char)src_next(src); } tok.text[i] \0; tok.type keyword_type(tok.text, TK_IDENT); return tok; } if (isdigit(c)) { /* 数字常量 */ int v 0; while (isdigit(src_peek(src))) { v v * 10 (src_next(src) - 0); } tok.type TK_NUMBER; tok.value v; snprintf(tok.text, sizeof(tok.text), %d, v); return tok; } tok.type operator_type(src, c); /* 多字符运算符: */ if (tok.type ! TK_ERROR) { src_next(src); /* 吃掉第二个字符 */ return tok; } tok.type one_char_operator(c); src_next(src); return tok; }这里的空白处理看似简单其实是血泪重灾区如果你漏掉对 \r 的处理在 Windows 下用 CRLF 换行的源文件会让行号全部错位实验报告里的截图对不上代码行号老师会直接质疑测试真实性。keyword_type 用二分查找或哈希都可以PL0 只有十几个关键字线性查表也够快但一定要把它做成独立函数方便单独测试。注意多字符运算符的识别顺序要先于单字符运算符。比如读到了 :必须先看下一个字符是不是 是就要读成赋值号否则 : 在这个语言里根本没有定义。顺序写反的话a : b 会被切成 : 和 两个 token语法分析器永远等不到它想要的赋值号。遇到无法识别的字符正确的做法是返回 TK_ERROR 并记录行号让上层报“第 n 行有非法字符”而不是静默跳过——很多同学在这里选择忽略结果后面语法分析因为缺了一个 token 而报出完全错位的错误位置。3.3 递归下降语法分析代码从EBNF到C函数的机械映射PL0 的算术表达式文法只有三个层次expression、term、factor正好对应加减、乘除、原子三个优先级。写成 EBNF 是expression :: [|-] term { (|-) term } term :: factor { (*|/) factor } factor :: NUMBER | IDENT | ( expression )这个文法没有左递归可以直接映射成递归下降函数。优先级是靠函数调用层级表达的expression 调 termterm 调 factor越底层优先级越高这是递归下降的核心机制学名叫优先级分层。int parse_expression(Parser *p) { if (p-tok.type TK_PLUS || p-tok.type TK_MINUS) { consume(p); /* 一元正负号 */ } parse_term(p); while (p-tok.type TK_PLUS || p-tok.type TK_MINUS) { consume(p); parse_term(p); } return 0; } int parse_term(Parser *p) { parse_factor(p); while (p-tok.type TK_TIMES || p-tok.type TK_DIVIDE) { consume(p); parse_factor(p); } return 0; } int parse_factor(Parser *p) { if (p-tok.type TK_NUMBER) { consume(p); return 0; } if (p-tok.type TK_IDENT) { consume(p); return 0; } if (p-tok.type TK_LPAREN) { consume(p); parse_expression(p); expect(p, TK_RPAREN); return 0; } error(p, factor: 期望 NUMBER、IDENT 或 (); return -1; }这段代码看起来短但里面有一个初学者都会踩的坑parse_term 调 parse_factor 时没有保存任何语义信息等后面加四元式生成时你会发现表达式树的左操作数无处存放。所以正式的实验代码里这些函数通常返回一个“地址描述符”结构体或者把子表达式结果存进 AST 结点。这也是语法分析器和生命周期语义分析天然耦合的原因——你在递归下降的同时就得决定每个非终结符的语义返回值等后面再回头改等于把语法分析器重写一遍。语法分析器测试时我建议单独做一个 dump 模式把每次 consume 的 token 按先后序列打印出来再和词法分析器的 token 流对比。只要这两条序列对得上语法分析端的定位错误就排除了大半。4. 中间代码生成、目标代码优化与实验报告模板三个需要提前准备的模块4.1 四元式生成与临时变量编号中间代码的三个必调参数四元式是 op、arg1、arg2、result 四个字段的数组结构PL0 的运算和跳转都能塞进去。常见做法是维护一个 Quad 数组和 next_quad 游标每归约出一个产生式就 emit 一条。这里有一个从开头就要锁死的约定临时变量从 t1 开始递增编号不要重复使用不要回收。typedef struct { int op; /* OP_PLUS, OP_MINUS, OP_TIMES, OP_DIVIDE, OP_LT, OP_JMP, OP_JZ */ int arg1; int arg2; int result; /* 变量索引或临时变量编号 t1, t2 ... */ } Quad; int temp_counter; Quad quads[1024]; int next_quad; int new_temp(void) { return -(temp_counter); /* 用负数表示临时变量符号表索引为正数 */ } void emit_quad(int op, int arg1, int arg2, int result) { if (next_quad 1024) { fprintf(stderr, 四元式表溢出实验程序已超过预期规模\n); exit(1); } quads[next_quad].op op; quads[next_quad].arg1 arg1; quads[next_quad].arg2 arg2; quads[next_quad].result result; next_quad; }new_temp 里用负数区分临时变量和符号表索引是一个很小的约定但能让代码生成阶段少写一半判断逻辑。四元式表固定 1024 上限在课程实验里远够用用数组而不是动态链表是为了让打印中间代码时顺序稳定实验报告里贴出的四元式编号不会因为内存分配变化而闪烁。arg1 和 arg2 对运算符四元式是操作数对跳转四元式 JMP/JZarg1 放的是跳转目标四元式编号等回填时再改。回填是中间代码生成里最容易黑匣子化的环节。处理 IF 和 WHILE 时你往往先发一条跳转四元式此时目标四元式还没生成只能先填一个占位值等条件分支语句体遍历完再回头改。这个占位值要单独记在一个变量里否则两个嵌套 IF 的跳转目标会互相覆盖。我会在 Parser 的语义动作里用一个 int 数组保存待回填的四元式下标每层条件嵌套入栈、退出出栈规则和符号表作用域一模一样。4.2 目标代码优化做到哪一层常量折叠、死代码删除的边界目标代码优化在课程实验里是最容易被做坏的部分。一个常见误区是引入大段寄存器分配和活跃变量分析算法结果优化器比编译器本体还复杂老师又不敢确定是不是你自己写的。课程定位的实验优化做到常量折叠、死代码删除和跳转消除就够了关键是要留下操作日志让每一步优化有据可查。优化手段做什么风险报告验证方式常量折叠把 CONST 定义和字面量的纯常量运算在编译期算掉改变除法取整语义优化前后四元式对比死代码删除删除 x : x 这类自赋值和恒假分支误删有副作用的 CALL 语句给一个含 CALL 的测试用例跳转消除把 JMP 到紧接着的下一条指令消掉与回填顺序耦合打印优化后的跳转序列死代码删除里最典型的问题在上面表格里也提到了PL0 的过程调用也有观测副作用只做数据依赖分析会误删 CALL。课程实验里我建议只对“赋值语句和算术四元式”做死代码删除过程调用一律视为活跃。这个边界意识比优化算法本身重要——你交上去的报告里如果写了这一条老师就知道你是真的踩过坑而不是在背概念。优化器的输入输出要保持“中间代码到中间代码”输出之后再 dump 一份四元式文件。这样优化器和代码生成器不耦合重跑一遍编译就能对比优化前后的两条四元式序列实验报告里的对比截图也就是这么来的。4.3 实验报告模板与学习笔记老师评分时读的不只是代码实验报告模板在资源整合里的作用常被低估。太多课程报告只贴源代码和最终截图缺少“这个实验我改了什么、遇到什么问题、怎么验证的”。一份能拿得出手的实验报告模板按这个结构组织实验目的与文法说明、模块设计与接口定义、关键代码与数据结构、测试用例与运行结果、问题踩坑与解决过程、附录完整代码路径。其中测试用例与运行结果是最有区分度的部分。测试用例要给出三种输入合法的完整 PL0 程序、边界条件下的合法程序空语句过程体、嵌套过程同名变量、故意写错的程序缺分号、括号不匹配、未声明变量。对每一种输入贴运行日志日志里要有解析到的行号。老师评分时读的是“这组测试能否证明你的模块边界是对的”而不是代码排版好不好看。记得把测试用例 .pl0 文件和对应输出一起归档报告里贴日志时标注输入文件路径让老师能一键复现。学习笔记的组织方式我建议按“一个实验模块一节”每节只记三样东西文法或状态转换图的推导过程、调试中真正踩过的报错原因、与教材默认实现的差异。比如 FIRST/FOLLOW 集合和递归下降的对应关系、四元式 op 码表为什么要这样设计都属于值得记的。把这些笔记整理进 docs 目录期末复习时你会感谢当时肯写笔记的自己。这里有经验笔记里一定要写“我原以为会怎样实际是怎样”这种反差记录才真正帮助理解只是抄讲义重点的话期末不会翻。5. 编译原理实验避坑指南从环境配置到验收的五个高频问题5.1 编译器报“未包含main类型”入口函数迷路的真相现象gcc 编译链接后报 ld 返回 1 exit status提示 undefined reference to main有的 IDE 会翻译成一句神秘的“编译器未包含 main 类型”。原因一种情况是 main.c 忘记写进 Makefile 的源文件列表另一种更隐蔽——词法分析器文件里定义了一个叫 main 的测试函数真正的入口在 parser.c 里两个 main 撞车还有一种是用了 MSVC 的旧项目模板入口函数被设置成了别的名字或者 main 返回值写了 void在 gcc 默认标准下直接不让编。解决单独维护 main.cMakefile 里把源文件列表写成OBJ lexer.o parser.o main.o这种变量链接时把 main.o 放最前面gcc 的链接顺序会影响符号解析。再加-Wall -Werrormain这类参数入口问题在编译阶段就暴露不用等到链接。每次换机器编译时第一件事是make clean再全量重编很多“昨天能跑今天不能”的玄学问题就是因为增量编译拿了旧的目标文件。5.2 二义性文法导致解析结果错乱悬垂else与优先级现象if a then if b then x : 1 else x : 2被解析成了if a then (if b then x : 1 else x : 2)和教材预期相反程序行为也完全不对。原因PL0 的 IF 和 ELSE 配对规则如果写成二义文法递归下降会按照就近匹配直接给出行为关键是你自己未必意识到这个行为已经嵌进了代码。算术表达式也一样如果 expression 没有分层a b * c 会被解析成 (a b) * c。解决把文法的 EBNF 先写清楚再写代码。算术表达式必须拆成 expression/term/factor 三层IF 语句的配对问题一种做法是规定 ELSE 必须和最内层未配对的 IF 匹配另一种是干脆在文法里禁止裸 IF 嵌套要求写IF ... THEN BEGIN ... END ELSE BEGIN ... END。写完 Parser 后用几个刁钻用例验证优先级不要只看正确路径这类问题在词法分析和语法分析联调的第二天集中爆发。5.3 符号表作用域不处理嵌套过程里同名变量的幽灵现象内层过程声明了和外层同名的变量编译时查到的始终是外层的值或者过程结束后符号表里还残留内层声明外层同名变量被污染。原因符号表没有按作用域链做压栈弹栈。常见实现错误是用一个扁平数组存符号插入时只做线性查找根本没有“当前过程是哪个”的概念。解决符号表项加 ScopeLevel 字段查找时从当前层往下找到最内层匹配项过程结束时把该层所有符号标记为不可见或整体弹出。PL0 只有嵌套过程这个链不会很复杂压栈弹栈逻辑用独立函数实现别散落在 semantic.c 各处。我自己的习惯是每次过程结束时导出一份当前符号表快照对比一下内层声明是否真的消失了这一步能把很多隐蔽错误挡在联调之前。5.4 gcc与MSVC行为差异同一份C代码两边结果不一样现象在教室用 MSVC 编译通过的实验代码拿回 Linux 用 gcc 编译直接报错最常见的报错位置是 for 循环里声明int iMSVC 的旧标准不支持这种写法。原因MSVC 对 C89/C99 的处理和 gcc 不一样老课程参考代码多半是 C89 风格变量声明必须在块开头。而 gcc 默认还可能按 GNU17 这类标准编译两边一迁移就暴露差异。解决在项目说明和 Makefile 里写死标准版本。gcc 加-stdc99 -WallMSVC 把 .c 文件改成 .cpp 后用 C 编译器编是一条省心路径或者干脆统一写成 C89 风格所有变量声明放到函数顶部。平台差异不属于算法难度纯属工程约定但每年都有小组卡在这里两三天而且这种问题你自己查不出来时很难在搜索里找到关键词。5.5 实验报告只有代码没有运行验证验收时被追问的第一现场现象报告里贴了完整源码和几张截图老师一追问“这个用例的输出为什么是这个数值”当场回答不上来。原因没有保留测试的输入文件和运行日志截图来源连自己也说不清。有的同学会临时跑一个用例补截图但那张图的路径在报告里根本对不上。解决把测试用例 .pl0 文件和对应的运行输出一起归档到 test 目录报告贴日志时标注“输入文件 test/if_else.pl0输出见下”让老师能复现。这也顺带解决一个信任问题凡是能一键重跑的实验评分争议都少得多。报告里还要加上这段日志是第几次编译生成的、用的哪个 Makefile 目标这些细节在验收时都是“这实验是自己做的”的有力证据。6. 把PL0实验环境变成可复用资产冒烟测试脚本与进阶验证方向6.1 冒烟测试脚本让五个模块一键回归到这一步代码已经能编译运行但你要让它能长期复用得写一个冒烟测试脚本跑一遍全流程。常见做法是把合法用例、非法用例、含优化前后对比的用例都放进 test 目录脚本逐个编译执行、对比退出码和中间代码输出#!/bin/bash # run_tests.sh —— 编译原理实验冒烟测试 PASS0 FAIL0 mkdir -p out for src in test/case_*.pl0; do name$(basename $src .pl0) ./pl0c $src out/${name}.ir 2 out/${name}.err if [ $? -eq 0 ] [ -s out/${name}.ir ]; then PASS$((PASS1)) echo [PASS] $name else FAIL$((FAIL1)) echo [FAIL] $name —— 见 out/${name}.err 第 1 行 fi done echo PASS$PASS FAIL$FAIL exit $FAIL这个脚本的价值在你改动符号表或者优化器之后立刻体现跑一遍哪几个用例挂掉错误文件里第一行就是定位线索。课程实验的五个模块层层堆叠改了中间代码生成如果无意间碰了语法分析那边脚本会立刻抓住回归。这也就是“代码仓库”和“抄来的代码”之间的分水岭——前者敢随时重新构建后者不敢。6.2 从课程实验到真实编译器下一步学什么跑通 PL0 这条链之后你其实已经掌握了一条通用的设计线前端按 token、语法结构拆解后端按中间表达和优化分层。下一步可以做的方向是把递归下降换成 flex/bison 自动生成器把四元式的解释执行换成真实指令选择把符号表从单整型扩展到带类型系统。每个方向都能单独成实验但原理都被压缩在这门课里只是规模和工程复杂度上了一个台阶。我自己的教训是当年急着把语法分析器写得“高级”引入了一堆抽象层级最后联调时错误被层层包装排错时间比写代码时间还长。后来养成的习惯是任何改动先跑一遍冒烟脚本再抓具体用例调试宁可慢一点也不要开着黑匣子瞎试。如果你也在做编译原理实验希望这套拆法能帮到你先保证依赖链清晰再追求优化与算法交付的不只是一份报告而是一个能反复重跑、敢让老师当面点下运行键的实验环境。本文还有配套的精品资源点击获取