PL/0编译器实验：用递归下降与虚拟机吃透编译原理核心链路

简介：面向编译原理课程的PL/0编译器完整实验实现，源自山东大学SDU教学实践，适合正在学习编译原理、准备课程设计或希望深入理解编译过程的计算机专业学生。项目采用C/C++语言编写，严格按照词法分析、语法分析、语义分析、符号表建立与虚拟执行的标准流程组织代码，涉及的BNF文法定义、递归下降分析等核心知识点均有对应实现，可清晰展示编译器从源码到运行的整体链路，对掌握编译前端到后端的衔接有直接帮助。压缩包共包含94个文件，以cpp/h/c源码、CMake构建配置、txt测试用例、out运行输出、png截图及docx实验报告为主，整体约513KB。已有104人学习下载，实验报告记录实现思路，测试用例和运行截图方便对照验证，适合作为课程作业参考或自学编译原理的实用范例。

1. PL/0 编译器实验：不只是课程作业，而是理解编译器前端的极简入口

很多人第一次接触编译原理，是被那本厚书里的状态转换图、LL(1) 分析表劝退的。直到在山东大学 SDU 的编译原理课程里拿到 PL/0 编译器这个实验，我才发现原来一个能跑通词法、语法、语义分析的最小编译器，代码量可以控制在几千行内。PL/0 是 Wirth 设计的教学语言，它砍掉了复杂类型系统和庞大的标准库，只保留变量声明、表达式、if/while、过程调用这些核心结构。这套 JiuCi-1-PL0_Compiler 的 C++ 实现包含完整的 lex / parse / vm 三层，源文件直接编译成指令在虚拟机上执行，不需要生成真实汇编就能看到运行结果。适合正在做课程设计的学生、想快速回顾编译器前端的在职开发，以及准备面试时需要突击编译原理细节的人。接下来我会拆开这个项目，从模块结构、构建方式到避坑点，完整走一遍。

2. 项目结构与核心模块：先看懂 lex / parse / vm 三层再动手

拿到 PL0_Compiler 源码包，第一件事不是急着编译，而是把目录结构理清楚。这个项目的核心文件分三层：词法分析在 lex.h / lex.cpp，语法分析在 parse.h / parse.cpp，虚拟机执行在 vm.h / vm.cpp，外加 data.h 定义公共数据结构，main.cpp 负责初始化 PL/0 虚拟机解释执行。

2.1 CMake 构建和测试模式：如何快速跑通第一个样例

项目根目录有 CMakeLists.txt，说明这是一个 CMake 管理的 C++ 项目。用 CLion 打开可以直接导入，命令行构建也很简单：

mkdir build && cd build cmake .. make

构建产物默认是 PL0_Compiler 可执行文件，运行后进入交互模式，可以逐行输入 PL/0 源码并立即看到结果。仓库里的 test 目录下准备了几个典型测试用例，比如乘除公约数、100 以内素数、1 到 10 的乘方，扫一眼这些代码就能明白 PL/0 语言的表达能力边界。

提示：cmake-build-debug 目录是 CLion 生成的本地构建缓存，不是源码的一部分，下载后可以直接删掉。

2.2 data.h 和 lex.cpp：词法分析器怎么把源码切成 token

词法分析是这个项目里最直观的部分。PL/0 的 token 类型不多，包括标识符、数字、保留关键字和运算符，data.h 里定义了枚举和符号表结构。词法分析的核心逻辑是扫描源字符流，跳过空白符，识别关键字和字母开头、数字开头、特殊符号三种路径。

我摘一段关键的 lex.cpp 逻辑，帮助你理解识别数字时的处理方式：

// 识别数字，同时检查是否超出整数范围 if (isdigit(ch)) { int num = 0; while (isdigit(ch)) { num = num * 10 + (ch - '0'); if (num > max_int) { error("常量溢出"); return; } ch = getChar(); } token = NUMBER; value = num; }

这段代码的作用是把连续的数字字符转换成整数值，同时做上溢检查。max_int 来自 data.h，实验里一般设成 32 位整数的最大值，防止用户输入超大常量导致后续 vm 计算溢出。很多初学者会漏掉这个检查，等运行一段带大数的程序时输出奇怪的负数，才回头来找问题。

2.3 parse.cpp 递归下降：用 EBNF 文法直接驱动语法分析

PL/0 的文法非常适合用递归下降来实现，因为它的产生式层级清晰：程序由块构成，块由声明和语句构成，语句又分为赋值、调用、if、while 等几种。parse.cpp 的函数命名基本和文法符号一一对应，比如 parse_statement、parse_expression、parse_term、parse_factor。

这里展示一个典型的因子识别逻辑，它要处理数字、括号表达式、标识符三种情况：

void Parser::parse_factor() { if (sym == NUMBER) { emit(LIT, num); // 把常量加载到虚拟机栈 getSym(); } else if (sym == LPAREN) { getSym(); parse_expression(); if (sym != RPAREN) error("缺少右括号"); getSym(); } else if (sym == IDENT) { ... } }

emit 函数负责生成中间代码指令，这里直接把因子对应的常量指令发出去。递归下降的好处是代码结构和文法一一对应，出错时能直接从调用栈定位到具体产生式。坏处是如果文法里有左递归就会死循环，所以 PL/0 的实验指导书里通常已经用 EBNF 消除了左递归，你只需要照着写即可。

2.4 vm.cpp 虚拟机：目标代码解释执行的可视化窗口

后端不生成 x86 汇编，而是生成 PL/0 虚拟机指令，比如 LIT、LOD、STO、CAL、INT、JMP、JPC、OPR 等等。vm.cpp 里就是一个循环，逐条取出指令并修改栈、寄存器、程序计数器。这是理解过程调用栈和跳转逻辑最直观的一层。

关键代码块像这样：

case LIT: // 将常量放入栈顶 s[sp + 1] = code[pc].a; sp++; break; case OPR: // 算术运算或关系运算 switch (code[pc].a) { case ADD: sp--; s[sp] = s[sp] + s[sp + 1]; break; case SUB: sp--; s[sp] = s[sp] - s[sp + 1]; break; ... } break;

运算符 OPR 的参数字段 a 决定具体做什么运算，这种设计在小型解释器中非常常见，指令码本身只有三层：f（功能）、a（参数），栈式虚拟机直接围绕 sp 指针展开工作。如果你之前只做过纯前端实验，看到这段会很爽——一条 LIT 指令对应源码中的一个数字字面量，执行流程完全透明。

3. 从源码到运行：构建细节、测试用例和参数调整

这一章重点回答两个问题：项目怎么跑起来，以及测试代码里到底在算什么。很多同学拿到压缩包后卡在不会构建，或者在测试模式里跳不出来，这里逐步展开。

3.1 构建参数说明与可执行文件用法

CMake 默认构建的是 Debug 模式，如果你需要更快的解释执行速度，建议显式指定 Release：

cmake -DCMAKE_BUILD_TYPE=Release .. make

项目里没有外部依赖，只要 C++ 编译环境能支持 C++11 以上即可。构建完成后运行./PL0_Compiler进入交互模式，它会提示输入源码文件路径，注意这里有时需要输入相对路径，有时是绝对路径，取决于启动程序时所在的目录。

我一般会创建一个input.pl0文件来存放测试代码，然后这样运行：

./PL0_Compiler < input.pl0

这样运行时 stdin 会直接读到整个文件，避免一行一行手动输入的麻烦。如果你在 Windows 下用 CLion 运行，注意设置工作目录为项目根目录，否则找不到 test 下的相对路径文件。

3.2 测试样例逐个拆解：乘除公约数、素数、乘方

test 目录里的样例覆盖了 PL/0 主要的语言特性，建议按难易程度逐个跑通。第一个PL0_code(乘除公约数乘方).png展示的是一个求最大公约数和乘方组合的程序，这里贴一个典型 PL/0 循环结构片段作为参考：

var x, y, result; begin x := 12; y := 8; while y <> 0 do begin result := x mod y; x := y; y := result; end end.

这段代码在 PL/0 虚拟机上执行时，会看到 while 循环配合 JPC 指令反复跳转。跑通这个样例，你就理解了条件跳转指令是怎么和栈顶值互动的。PL0_code3(100以内的素数).png则嵌套了 for 风格的循环（用 while 模拟）和取余操作，是检验 OPR 指令全集是否完备的好用例。

3.3 修改语言扩展：从只读项目变成可玩的项目

实验做完后，很多学生会想加点东西。最常见的是增加%（取模）运算符，这需要三处改动：lex.cpp 里把%识别成 MODSYM；parse.cpp 里在表达式层级允许取模出现在 factor 或者 term 位置；vm.cpp 的 OPR 分支里新增 MOD 指令实现。

// lex.cpp 中识别 % else if (ch == '%') { getChar(); sym = MODSYM; return; }

改完编译再跑素数的例子，看看是否能正确输出 100 以内的素数。如果结果不对，优先检查 vm.cpp 里取模运算的栈操作顺序，因为栈式虚拟机是从栈顶弹出两个操作数的，顺序一颠倒就会变成y mod x而不是x mod y。这是扩展语法时最经典的坑，后面避坑章节还会展开。

4. 避坑排查：我从这份实验里踩过的五个真实问题

4.1 编译错误：undefined reference to 'lex::getSym()' 之类

现象：代码按 README 步骤编译，链接时报找不到词法或语法分析函数，明明源码文件都在。
原因：CMakeLists.txt 的 add_executable 只列了 main.cpp，没把 lex.cpp 和 parse.cpp 放进去，源文件编译归编译，链接时符号缺失。
解决：把全部源文件加到 CMakeLists 里，或者用aux_source_directory(. SRC)自动收集当前目录下所有 .cpp 文件。

4.2 运行 test 样例时死循环或栈溢出

现象：跑包含 while 循环的测试程序时，程序卡住，CPU 占用 100%，或报栈溢出。
原因：语法分析时 while 语句没有正确生成跳转指令，跳转目标的地址计算错误，导致循环条件永远为真。
解决：检查 parse_while 函数里 JPC 指令的目标 label 和循环结束跳转的对应关系，通常是用 backpatch 方式先留空地址，循环体生成后再回填。具体做法是记住 JPC 指令的地址，在循环体结束后把当前指令地址回填到 JPC 的跳转参数。

4.3 输入空格和换行被当成非法字符

现象：复制网上的 PL/0 程序运行时，出现非法字符错误。
原因：源码文件中包含 Windows 的换行符\r\n，词法分析器只跳过了\n和空格，没有忽略\r。
解决：在词法分析器的跳过空白逻辑中加入if (ch == '\r')处理，或者用编辑器把文件转换为 LF 换行格式。

4.4 变量声明作用域混乱

现象：var x;声明后，在 if 分支里对一个同名变量赋值，结果过程内部和外部变量互相覆盖。
原因：符号表和层号（depth）管理有误，过程块开辟的栈段没有正确隔离。
解决：PL/0 实现里需要在进入过程时增加层号，并在符号表中记录变量的层号，查找符号时从当前层向第 0 层逐层找。检查 parse_block 中的 enter 符号和 symbol table 的 lookup 逻辑。

4.5 打印和调试信息缺失，没法定位指令执行到哪

现象：程序出错，但 vm 执行完没有显示任何中间状态，不知道错在哪条指令。
原因：vm.cpp 没有提供单步跟踪模式。
解决：在 vm 主循环里加调试开关，每执行一条指令打印 pc、sp、指令类型和栈顶几个值：

if (debug) { printf("pc=%d sp=%d f=%d a=%d top=%d\n", pc, sp, code[pc].f, code[pc].a, s[sp]); }

加完之后立刻能看到是哪个跳转指令跳错了，代码定位时间直接砍半。

5. 报告撰写与测试截图：实验报告怎么写才不白做

这个项目包里带了编译原理实验报告.docx，是上一届完成的模板。报告内容通常包括实验目的、文法定义、模块设计、核心代码片段、测试用例和结果分析。

5.1 报告结构模板参考

报告要有截图，仓库里的PL0_code*.png就是例子的运行结果。但不要直接拿别人截图交差，因为同一份代码在不同编译方式下输出内容可能相同，但老师要求的是你的实验过程记录。

5.2 测试截图技巧：命令行下怎么输出清晰可读的结果

如果你用黑底白字的终端截图，记得调整字体大小到 14px 以上，并把运行窗口宽度拉大，保证指令信息和程序输出完整可见。推荐把最终测试程序的结果单独用printf打印，不要和内部调试输出混在一起。

一个实用做法是：修改 vm.cpp 的初始化函数，让 OPR.OUT 指令输出变量值时自动换行，并且支持输出字符串常量，这样测试素数时可以直接打印提示语，截图更有说服力。但注意这一改动不影响评分，只是让报告更好看。

5.3 代码量少却要写实验感悟怎么办

如果你发现这个项目的代码量比自己预期的少，写报告时很容易显得空。这时不要凑字数，而是把你踩过的坑、改过的 bug 写成实验过程完整性描述。比如在“遇到的问题”章节写递归下降匹配右括号失败导致整个语句跳过，解决方法是报错后继续恢复到分号位置同步。这类细节才是老师想看的，也是你面试时讲项目的最佳素材。

6. 进阶玩法：给 PL/0 编译器加一个条件表达式扩展

到这里整个项目已经能跑通，但如果只是跑通就停手，实验的价值只发挥了 60%。下面给出一个非常具体的扩展方向：给表达式增加and、or逻辑运算，扩展后可以写出if (x > 0 and y > 0)这样的条件。PL/0 原始文法不支持逻辑运算符，需要修改三处。

首先在 lex.cpp 增加关键字识别，添加ANDSYM和ORSYM。其次在 parse.cpp 的表达式层级中插入新的产生式：逻辑表达式作为最外层，包含关系表达式和逻辑运算符的组合。最后在 vm.cpp 的 OPR 分支中实现逻辑与和逻辑或指令。

// vm.cpp OPR 新增逻辑与 case AND: sp--; s[sp] = (s[sp] != 0) && (s[sp + 1] != 0) ? 1 : 0; break; case OR: sp--; s[sp] = (s[sp] != 0) || (s[sp + 1] != 0) ? 1 : 0; break;

注意：PL/0 虚拟机的栈里没有布尔类型，这里的逻辑运算结果统一用 0 或 1 表示非零条件，供 JPC 指令识别。在语法分析端，需要将逻辑表达式作为比关系表达式更上层的结构，否则if (a > 0 and b > 0)会被错误解析产生语法错误。

扩展后一定要跑一个带逻辑条件的综合测试，比如：

var x, y; begin x := 5; y := 7; if x > 3 and y < 10 then write(x + y) end.

满意的运行结果会输出 12。如果输出 5 或者 7，大概率是我前面说的栈操作数顺序问题，检查 and 指令左右操作数是否反了。做完这个扩展，你对递归下降文法的层序敏感度就会明显提升，以后再碰 JSON parser 或者 SQL parser，心里门清。

从那以后，我每次拿到这类教学性质的项目，都会默认扩展一个原文法没有覆盖的语法特性，而不是只满足于通过测试用例。因为扩展语法逼你把词法、语法、语义、虚拟机执行整个链条重新串一遍，这个过程中踩的坑和用的调试手段，比跑通十个现成样例都值钱。希望这套 PL/0 编译器代码和这份拆解，能帮你在课程实验里少熬几个夜，多攒一点真正能讲出口的细节。

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