简介：南京航空航天大学编译原理课程设计的完整实现，采用Python语言编写PL0语言编译器，面向计算机专业本科生、编译原理课程学习者以及需要完成同类课设的开发者。压缩包共8个文件，包含5个Python源码文件（词法分析器、语法分析、语义分析、后端及测试版本）、1份编译原理课设报告（doc）、1个README说明和1个article.txt文本，整体大小约792KB。资源内容覆盖词法分析、语法分析、语义分析、中间代码生成与后端代码生成等编译器核心流程，并通过报告详细展示从PL0语法设计到目标代码输出的实现思路与关键代码。学习者可借助完整源码对照理解上下文无关文法、递归下降分析和抽象语法树等概念，也能在调试与扩展过程中掌握编译器前端与后端的衔接方式。已有181人学习下载，适合作为课程设计参考或编译原理实践入门素材。
1. Python版PL0课设包值不值：先看它把编译器拆成了哪五块
编译原理课设，加上PL0，再加上Python，这三个词放到一起，目标就很明确：用尽量短的时间把“字符流到可执行”这条链路走通。这份NUAA的PL0课程设计包把编译器拆成词法分析器.py、语法分析.py、语义分析.py、后端.py四个独立脚本，再配一份编译原理课设报告.doc和README，前端三段和后端输出一一对应。它的价值不在代码量，而在流程完整度：面对PL0这种教学语言，词法、语法、语义、代码生成各个环节都能单独看、单独验。适合正在做编译原理课设，需要快速摸清PL0全流程的本科生，也适合想找一份模块化参照系、搞清楚前端如何衔接后端的自学者。接下来按“文件结构→各模块实现→常见坑→答辩验证”的顺序拆。
2. 词法分析器：从字符流到token流的实现与四个边界坑
词法分析器.py 是这套包里最能独立演示的模块。把一段PL0源程序喂进去，吐出来的是带行号的token列表。判断这份词法分析器写得好不好，我只看三点：保留字是否独立成表、数字和标识符是否做到“无回退”扫描、错误消息是否直接带行号。下面按这四个点拆。
2.1 为什么单独拆一个文件：token契约先定下来
编译器前端的三个模块如果写在同一个文件里，最麻烦的不是代码长，而是改一处牵连三处。词法分析器单独拆出来之后，它和语法分析的契约就是一个列表：[ (kind, value, line), ... ]。kind 是 ident、number、keyword、运算符之一；value 是该 token 的原文或数值；line 用于报错。后面语法分析.py 只认这个结构，不关心源文件长什么样。
PL0 的 token 集合其实很小，分类如下：
| 类别 | 内容 |
|---|---|
| 关键字 | begin end if then while do const var procedure call read write odd |
| 标识符 | 字母开头的字母数字串 |
| 数字 | 无符号整数 |
| 运算符/分隔符 | + - * / = <> < <= > >= := ( ) , ; . |
| 结束符 | eof |
这个表对应到代码里的关键字集合时，我不建议用一长串 if 去判断，直接一个 set 查表最干净。注意 PL0 的相等判断是单个=，不是==；赋值是:=，和 Pascal 语法一致。
2.2 主循环关键分支：保留字表、数字、标识符怎么共存
我一般会把 lex 写成一个 while 循环，每轮至少移动一个字符，这是后面所有“死循环”问题的总开关。核心骨架如下：
def lex(source: str) -> list: tokens = [] i = 0 line = 1 n = len(source) keywords = {"begin", "end", "if", "then", "while", "do", "const", "var", "procedure", "call", "read", "write", "odd"} while i < n: c = source[i] if c in " \t\r": # 空白直接跳过 i += 1 continue if c == "\n": # 换行推进行号 line += 1 i += 1 continue if c.isalpha(): # 标识符或关键字 j = i while j < n and (source[j].isalnum() or source[j] == "_"): j += 1 word = source[i:j] kind = "kw" if word in keywords else "ident" tokens.append((kind, word, line)) i = j continue if c.isdigit(): # 数字，PL0 只认整数 j = i while j < n and source[j].isdigit(): j += 1 tokens.append(("number", int(source[i:j]), line)) i = j continue # 运算符和分隔符在下一小节展开 ... tokens.append(("eof", None, line)) return tokens这段代码的逻辑核心是“双层扫描”：isalpha分支里内层while把游标推进到标识符末尾，外层循环再继续处理下一个字符。好处是标识符和关键字不需要向前看，也不需要事后回退；坏处是内层循环的边界条件必须同时检查j < n，否则源文件以字母结尾时会越界。值得注意的参数细节有两个：source[j].isalnum()允许数字跟在字母后，这是多数课设版本的宽松做法；int(source[i:j])直接把子串转整数，如果课设要求检测“数字超过五位”这类错误，要在这之前加一个长度判断。
这里还有个顺序坑：标识符判断要先于数字判断。反过来写也不会崩，但遇到123abc这种 PL0 里不合法的写法时，先吃数字会把错误拆成“number 123 + ident abc”，报错信息就完全走偏了。我习惯在报错里把这类情况单独拎出来，宁可多一个分支也不要让 token 流静默失真。
2.3 双字符符号:=、<=、>=与行号统计
PL0 里最容易写错的不是表达式，而是那几个双字符符号。赋值号:=由冒号和等号组成，如果不做二次判断，:=会被拆成两个非法 token。常见处理方式是在遇到:、<、>时，先偷看下一个字符：
if c == ":": if i + 1 < n and source[i + 1] == "=": tokens.append(("becomes", ":=", line)) i += 2 else: raise LexError(f"line {line}: ':' must be followed by '='") continue if c == "<": if i + 1 < n and source[i + 1] == "=": tokens.append(("leq", "<=", line)) i += 2 elif i + 1 < n and source[i + 1] == ">": tokens.append(("neq", "<>", line)) i += 2 else: tokens.append(("lss", "<", line)) i += 1 continue每个分支都先检查i + 1 < n，这是防止在文件末尾读取source[i+1]越界的关键。行号统计放在c == "\n"那一条里，注意 Windows 源文件的行尾是\r\n，外层把\r当空白跳过，只有\n才累加行号，这样line永远指向真实行。如果漏了\r这一层，Windows 下写出来的报告里所有报错行号都会偏。
2.4 词法错误要报到第几行：错误消息的格式化细节
很多课设版本的词法分析器遇到非法字符直接print一行文字然后退出，命令行里能看，进报告就不好看了。我习惯把错误组织成line {line}: ...并抛异常，由外层 main 统一捕获：
class LexError(Exception): pass def main(): src = open(sys.argv[1], encoding="utf-8").read() try: for t in lex(src): print(t) except LexError as e: print(f"lex failed: {e}", file=sys.stderr) sys.exit(1)这里有个容易被忽略的小技巧：line信息不要在 lex 里单独维护副本，而是在遇到\n时统一line += 1，这样所有 token 共享同一个变量，不会出现“报错行号比实际靠前一行”的问题。后面语法分析报错也要行号时，直接从 token 的第三个字段取即可，不用回源文件数换行。词法层把打印和报错分开，这份代码进可做命令行工具，退可被语法分析器当库 import。
3. 递归下降语法分析：PL0表达式三级文法怎么变成可运行代码
词法分析器输出 token 流之后，真正决定“这个程序合不合法”的是语法分析.py。PL0 的文法规模小，完全不需要引入 yacc 或 lark，递归下降是它最自然的选择。先把文法层级定下来，再看 expression、term、factor 三个函数怎么写。
3.1 为什么不用生成器：LL(1)无冲突与单token前瞻
PL0 表达式文法可以写成三行：
expression → term { (+|-) term } term → factor { (*|/) factor } factor → number | ident | ( expression ) | odd expression这三条产生式里每个非终结符的 first 集互不重叠：expression 的第一个候选是 term，term 的第一个候选是 factor，factor 的 first 集是 number、ident、左括号、odd。所以这张表天然满足 LL(1)，递归下降只需要维护一个前瞻 token。选递归下降还有一个答辩上的理由：你能在报告里画调用关系树，老师问“这里怎么实现”时，直接说“我在 factor 里遇到左括号就递归调 expression”就能讲清。
语句部分则一般由这几条产生式支撑：
statement → ident := expression | begin statement { ; statement } end | if condition then statement | while condition do statement | read ( ident ) | write ( expression ) | call ident语句部分用同样的递归下降方式处理，注意一条 statement 必须能消费到下一个分隔符为止，否则 begin...end 的复合语句会漏掉分号。
3.2 expression、term、factor 三个函数的骨架与返回值设计
语法分析这一层我通常不直接生成机器码，而是先建一棵极简 AST。每个函数返回一个元组，第一个元素是节点类型，后面是子节点和位置。这样语义分析查表时不用再回头读 token 流。
class Parser: def __init__(self, tokens): self.tokens = tokens self.pos = 0 def peek(self): return self.tokens[self.pos] def advance(self): t = self.tokens[self.pos] self.pos += 1 return t def expression(self): left = self.term() while self.peek()[0] in ("plus", "minus"): op = self.advance() right = self.term() left = ("binop", op[1], left, right, op[2]) return left def term(self): left = self.factor() while self.peek()[0] in ("times", "slash"): op = self.advance() right = self.factor() left = ("binop", op[1], left, right, op[2]) return left def factor(self): t = self.peek() if t[0] == "number": return ("num", t[1], t[2]) if t[0] == "ident": return ("var", t[1], t[2]) if t[0] == "lparen": self.advance() e = self.expression() self.expect("rparen") return e raise ParseError(f"line {t[2]}: unexpected token {t[1]!r}")各函数返回值设计是有讲究的：expression和term返回的都是左结合二元运算的 AST 节点，factor返回叶节点或括号内子表达式。节点里我在最后一个位置放行号，语义分析阶段报错时能直接带出位置。重点看 while 循环的终止条件：self.peek()[0] in ("plus", "minus")，意思是“下一个 token 还是加号或减号，就继续合并右子树”，天然实现左结合；如果改成expression() + expression()这种写法，遇到a-b-c就会错成右结合，生成的三地址码和原意完全不同。
3.3 lookahead 与 token 越界：parser 最隐蔽的崩溃点
递归下降最常见的运行时崩溃是IndexError: list index out of range。原因很一致：expect检查 token 类型不匹配时，调用点又没有对 eof 做判断，下一次self.tokens[self.pos]就越界了。处理办法是把“消耗 token”集中到一个函数里，所有错误路径先抛异常再结束，而不是试图跳过几个 token 继续解析：
def expect(self, kind): t = self.tokens[self.pos] if t[0] != kind: raise ParseError( f"line {t[2]}: expected {kind}, got {t[0]} ({t[1]!r})") self.pos += 1 return t注意：判断 eof 不能只放在 expect 的 else 分支里就算完。处理
if语句时如果源文件在 then 后面直接结束，expect 会报“expected ident, got eof”，用户看不出缺了什么。更好的做法是在 parse_program 末尾强制要求最后一个 token 是 period（.），其余情况统一报“程序应以点号结束”，一眼就知道错在哪。
3.4 错误定位的技巧：报“期望什么”比报“第几行”更好用
第一次做课设时我只会写print("error at line", line)，答辩被问“这个错误具体是什么”时答不上来。后来统一成“期望＋实际”的格式：把期望的 token 类型和实际拿到的 token 都打印出来。比如 expect 抛出的消息是line 7: expected then, got semicolon (;)，这种消息对调试有实际帮助：semicolon 出现在 then 的位置，通常说明上一句语句漏了 end，或者多了分号。把这条经验放到整个 parser 里，所有 expect 都走同一个格式化函数，后期加错误恢复或警告功能时只需要改这一处。
4. 语义分析与后端：符号表、作用域和P-code生成的配合方式
词法、语法解决的是“读得懂”，语义分析解决的是“声明得合理”，后端解决的是“能不能跑”。这套包里语义分析.py 和 后端.py 正好把后半截分开。重点说三个配合点：两版语义脚本怎么取舍、符号表怎么设计、P-code 怎么生成。
4.1 同目录两份语义分析脚本：测试版与正式版怎么分工
包里有语义分析.py 和 语义分析_测试版本.py 两个文件。按课设常见套路，前者是最终提交版，后者是开发过程中的调试版。调试版一般会把“未声明变量”降级成警告，甚至遇到重复声明只打印信息不终止，方便你连续观察多条语义错误；正式版则是严格模式，任何非法引用都立即中止编译。如果你在跑样例时发现两版行为不一样，先别急着怀疑编译器，先确认是不是故意留的宽松开关。我的建议是两个脚本都保留，答辩时给老师展示“宽松版先看全量错误、严格版再验证”，反而比只留一个更能说明你做过系统调试。
4.2 符号表：name、level、address 缺一不可
PL0 的符号表不需要哈希表，一个线性表就够，原因是在小规模程序下查找性能根本不是瓶颈，可读性和打印性才是。每个符号固定记录四个字段：
| 字段 | 含义 |
|---|---|
| name | 标识符原文 |
| kind | const、var、procedure 之一 |
| level | 当前过程嵌套深度 |
| address | 常量值 / 变量相对栈基址偏移 / 过程入口代码号 |
其中 level 的作用经常被忽略：没有它，过程嵌套时同名变量会查错层。address 在 const、var、procedure 三种 kind 下语义完全不同，填错了后面取数就会拿到非法位置。经典实现里 var 按声明顺序分配地址 0、1、2……，procedure 的 address 填跳转目标指令号，等代码生成完再回填。
class SymbolTable: def __init__(self): self.table = [] self.level = 0 def enter(self, name, kind, address, line): if self.lookup(name) is not None: raise SemanticError(f"line {line}: duplicate symbol '{name}'") self.table.append({ "name": name, "kind": kind, "level": self.level, "address": address, }) def lookup(self, name): for i in range(len(self.table) - 1, -1, -1): if self.table[i]["name"] == name: return self.table[i] return Noneenter里先lookup再append的顺序是坑点：如果先 append 再查重，会查到刚插入的自己，重复声明永远发现不了。lookup从表尾往前遍历，是因为 PL0 的声明顺序决定内层过程先入表，从后往前查能天然实现“先找最近作用域”；如果从前往后查，内层变量会被外层同名变量一直屏蔽。
4.3 后端生成P-code：指令表的组织与解释执行器
后端.py 的职责是把语义分析通过后的中间表示转成一组定长指令。课设里最常见的中间代码是经典 P-code，指令格式统一为三元组(op, a, b)：
| op | a、b 含义 |
|---|---|
| LIT | 把常量 a 压栈 |
| LOD | 从 level a、偏移 b 处取变量压栈 |
| STO | 把栈顶存入 level a、偏移 b |
| CAL | 调用 number a 对应的过程入口 |
| JMP / JPC | 无条件 / 条件跳转到 a |
| OPR | 用 a 区分加减乘除、odd、读写等操作 |
指令生成用一个列表即可，指令号就是列表下标，这样填充跳转目标时可以占位后回填：
class CodeGen: def __init__(self): self.code = [] def emit(self, op, a=0, b=0): self.code.append((op, a, b)) return len(self.code) - 1 # 返回指令号，供跳转回填 def backpatch(self, addr, target): self.code[addr] = (self.code[addr][0], target, self.code[addr][2])跳转回填是 P-code 生成里最容易讲清楚、也最容易写错的部分。以 while 循环为例，先 emit 一个 JPC 占位，循环体生成后把循环开始地址填回 JPC 的 a 字段，循环结束地址填给循环体末尾的 JMP；顺序填反就是死循环或跳过循环体。解释执行器则直接模拟一个栈：
def run(entry, code, max_stack=1000): stack = [] # 数据栈 pc = entry while True: op, a, b = code[pc] if op == "LIT": stack.append(a) elif op == "OPR" and a == 0: # 约定: OPR 0 表示返回 break pc += 1这里把 OPR 的子操作用 a 区分（0 返回、1 加、2 减、3 乘、4 除等），是经典 Pascal P4 的约定。解释执行的优点是每步都能打印栈内容，答辩时可以直接演示“代码生成→出栈结果”的对应关系；缺点是和真实机器码差一层，所以报告里写“生成机器码”时，我会改成“为 PL0 虚拟机生成目标指令”，避免被老师追问汇编指令时露怯。
4.4 语义分析到后端的数据传递：谁生成指令，谁消费指令
这套包里的衔接方式是：语义分析通过后，语法分析阶段建的 AST 树交给后端，后端按树节点递归 emit。以赋值语句x := y + 1为例，流程是后端先对右侧表达式求值，再对左侧变量地址 emit STO。表达式求值顺序是后序遍历：先左子树、再右子树、最后根节点的运算，这样栈上的次序正好配合 OPR。
验证这条链路对不对，我一般不等执行结果，直接把生成的 P-code 打出来人工核对三件事：LIT 常量是否按源码顺序入栈、LOD 的 level/address 是否指向符号表里的正确项、跳转指令是否落在合理行。这三项都对了，执行结果基本不会翻车。
5. 常见问题排查：PL0课设里最典型的五个翻车点
这份包按“词法→语法→语义→后端”的顺序跑过几遍之后，遇到的高频问题基本能分成下面五类。每一条都是“现象 → 原因 → 解决”的记录，可以对着排查。
5.1 现象：注释处理把整个源文件吞掉，输出只有 eof
原因：词法分析器里加了注释支持（比如/* ... */跨行或//到行尾），扫描注释的循环条件写成了“没看到结束符就把 i 一直往后推”；源文件末尾少了结束符时，外层 while 一路推进到 n 并退出，中间所有 token 全部丢失。更隐蔽的是//注释的换行处理漏了line += 1，后面的行号全部错位。 解决：注释扫描也要遵守“每次至少推进一个字符”的原则；遇到未闭合注释直接抛 LexError，不要静默跳到 EOF。跨行注释里每遇到\n同样要累加行号。
5.2 现象：非法字符（如 @、#）一输入，程序卡死没有任何输出
原因：lex 主循环对未知字符没有走任何分支，i 没有变化，while 条件始终成立，形成死循环。终端看起来就是“运行后无输出”，但 CPU 占满。 解决：在 lex 的 else 分支里抛异常并附带行号：
else: raise LexError(f"line {line}: unexpected character {c!r}")如果报告里写了“自动跳过非法字符”，就在 else 里i += 1; continue，同时把警告记录到 warning 列表，答辩时拿出来说明设计选择。
5.3 现象：标识符数量超限报错，但报错行却不是真正的超限位置
原因：PL0 经典实现会限制符号表大小，课设版本经常写成“插入时发现 table 已满就报错”，报错却用当前 token 的 line，而实际触发超限的是更早声明的符号。 解决：enter 接口带上声明位置的 line，报错时用符号自身的行号；如果不想给接口加参数，就在读完整段声明块之后再检查数量上限。
if len(self.table) >= self.max_sym: raise SemanticError( f"line {line}: symbol table overflow at '{name}'")5.4 现象：语义分析_测试版本.py 跑样例没事，换成语义分析.py 就报“未声明变量”
原因：测试版为了连续看多条错误，把未声明变量降级成警告，甚至自动往符号表里塞一个空符号；正式版按标准语义要求“先声明后引用”，两版行为自然不同。 解决：以正式版为最终验收，测试版只作排错辅助。如果正式版报未声明，回去查源程序里该变量的声明是否在引用之前；PL0 不允许使用未声明过程变量，这也是需要单独检查的点。
5.5 现象：Windows 命令行下打印中文报错信息乱码，报告截图很难看
原因：脚本文件以 UTF-8 保存，Windows 控制台默认用 GBK 解码输出，打印中文说明或中文字段名时就乱码；如果再叠加open(...).read()未指定编码，源文件里的中文注释也会报解码错误。 解决：在 main 入口强制指定编码，并顺手重配标准输出：
import sys sys.stdout.reconfigure(encoding="utf-8", errors="replace") src = open(sys.argv[1], encoding="utf-8").read()errors="replace"保证个别乱码字节不会让整个程序崩掉，而是替换成占位符。命令行里如果还是显示乱码，用PYTHONIOENCODING=utf-8 python 语法分析.py test.pl0运行即可。
6. 答辩前验证：trace开关、六组PL0用例与可展示的中间产物
6.1 六组用例覆盖到什么程度
答辩现场老师通常会先问“测试过哪些情况”，我一般准备六组最小用例，每组只测一个点。不追求覆盖面，追求“每个阶段有对应输出”：
| 用例 | 源码特征 | 覆盖模块 |
|---|---|---|
| 1 | const a=5; 输出 a | 词法、符号表、LIT |
| 2 | var x; x:=a+1; 输出 x | 赋值 STO、LOD |
| 3 | if x<10 then ... | 条件跳转 JPC |
| 4 | while n>0 do n:=n-1 | 循环回填 JMP/JPC |
| 5 | procedure p; 主线 call p | 嵌套过程与 CAL |
| 6 | odd 与 begin...end 复合 | 运算符 OPR、语句嵌套 |
6.2 trace 开关怎么加
在 CodeGen 的 emit 里加一个全局 TRACE，生成每条指令时把三元组打印到屏幕。开 trace 跑一两次，生成过程就具备可展示性。
TRACE = True def emit(self, op, a=0, b=0): self.code.append((op, a, b)) if TRACE: print(f"[code@{len(self.code)-1}] {op:4s} {a:3d} {b:3d}") return len(self.code) - 1改成环境变量控制更省事：TRACE = os.environ.get("TRACE") == "1"，平时不开，答辩前再打开。
6.3 演示时看什么
我自己的答辩顺序是固定四步：第一步跑词法分析器确认 token 流；第二步跑语法分析看 AST 缩进打印；第三步开 trace 看 P-code 逐条生成；第四步执行并核对最终输出。四步都打印出来，再配合课设报告里的流程图，整个编译链路就讲全了。
最后补一个习惯：从那以后我每次拿到课设包，第一件事不是读报告，而是把词法分析器单独拖进命令行，喂一段三行 PL0 看 token 输出；等看到 P-code 逐条生成，才敢说这份代码我摸透了。这个过程放到你自己的项目里，就是把“先跑通最小样例”强制前置——它能在你读不懂任何大模块之前，先确认整条流水线是通的。希望帮到你。
本文还有配套的精品资源，点击获取
