同济大学编译原理课设：类C编译器从词法分析到四元式生成的完整实现与避坑指南

简介：这份资源是同济大学编译原理课程设计的类C编译器完整项目源码，面向计算机、软件工程、人工智能、通信、自动化等专业的在校学生与教师，可用于课程设计、作业提交或项目初期立项演示。项目已获导师认可，答辩评审95分，代码在mac、Windows 10/11及Linux环境下均测试运行成功。压缩包共21个文件，约40KB，以cpp与h源码文件为主，涵盖词法分析、语法与语义分析、中间代码生成、目标代码生成及优化等编译器核心模块，另附任务书doc、说明文档md、测试用例txt与LICENSE等资料，结构清晰、便于按模块研读。目前已有148人学习关注。读者可据此掌握类C编译器的完整实现流程，理解各阶段算法与模块衔接，并在此基础上修改扩展功能，适合作为课设参考与进阶学习素材。

1. 同济大学编译原理课设：类C编译器到底要交什么

很多人第一次看到“同济大学编译原理课程设计 类C编译器”这个题目，第一反应是去搜“编译原理第三版答案”或者“编译原理实验”，想找一份现成的语法分析代码交差。但真正做过这门课设的人都知道，类C编译器的验收标准不是“能跑就行”，而是你能不能把词法分析、语法分析、语义分析、中间代码生成这条链路完整地串起来，并且让一个包含函数定义、数组、while循环、if-else分支的测试用例顺利通过。同济的课设通常要求实现一个子集编译器，输入是类C语言源程序，输出是四元式或汇编风格的中间代码，部分年份还要求做简单的常量折叠和死代码消除。这个方向适合两类人：一类是想拿高分、愿意花两三天啃透递归下降和LLVM IR映射的硬核选手；另一类是只想及格、但至少得让词法分析器不把int main()识别成三个错误token的普通同学。源码和部署文档的意义在于，它把“从零手写”变成“先跑通再改”，但前提是你得知道每一层在干什么，否则改一个参数就全盘崩溃。

2. 类C编译器的最小可行架构：从词法到四元式

2.1 为什么选递归下降而不是Yacc/Bison

同济课设的类C语言子集通常包含变量声明、赋值、算术表达式、关系表达式、if-else、while、函数定义和调用。这种文法用递归下降手写，比用Yacc/Bison生成更可控，因为你需要在中途插入语义动作，比如符号表插入、类型检查、临时变量生成。Yacc的$$和$1在复杂语义动作里容易写成一团乱麻，而递归下降的每个函数对应一个非终结符，调试时直接打断点就能看到当前解析到哪个token。我一般会先写词法分析器，把关键字、标识符、数字、运算符、界符分成五类，然后用一个Token结构体保存类型、值和行号。词法分析的核心是最大匹配原则：遇到=时先看下一个字符是不是=，是就返回EQ，否则返回ASSIGN。这个细节如果漏了，if (a == b)会被解析成if (a = = b)，语法分析直接报错。

// lexer.c 片段：最大匹配处理双字符运算符 Token next_token() { skip_whitespace(); char c = peek(); if (isdigit(c)) return parse_number(); if (isalpha(c) || c == '_') return parse_identifier(); switch (c) { case '=': advance(); if (peek() == '=') { advance(); return make_token(TOKEN_EQ, "=="); } return make_token(TOKEN_ASSIGN, "="); case '<': advance(); if (peek() == '=') { advance(); return make_token(TOKEN_LE, "<="); } return make_token(TOKEN_LT, "<"); // 其他运算符类似处理 } }

这段代码的逻辑是先跳过空白，然后根据首字符分派。peek()只看不取，advance()取走当前字符。参数说明：TOKEN_EQ和TOKEN_ASSIGN是枚举值，分别对应==和=。注意parse_number要处理多位整数，parse_identifier要查关键字表，把while、if、int这些从标识符里区分出来。常见翻车点是忘记处理注释，//和/* */如果不在词法阶段过滤掉，语法分析会把注释内容当成token，报一堆莫名其妙的错。

2.2 符号表与类型检查的插入时机

符号表用哈希表或简单的链表数组都行，关键是插入和查找的时机。函数定义时，先把函数名和返回类型插入全局符号表，然后进入函数体，把参数和局部变量插入当前作用域。类C语言通常没有块级作用域，所以一个函数一个符号表就够了。类型检查主要做两件事：赋值时左右类型匹配，运算时操作数类型合法。比如int a; a = 3.14;应该报“类型不匹配”或者做隐式转换，但课设通常要求报错。我一般会在语法分析生成AST之后，再遍历一遍AST做语义检查，这样比在递归下降过程中边解析边检查更清晰，因为递归下降的回溯能力弱，一旦发现类型错误很难优雅地恢复。

// sema.c 片段：赋值语句的类型检查 void check_assign(ASTNode *node) { Symbol *left = lookup_symbol(node->left->name); if (!left) { error(node->line, "未声明的变量 %s", node->left->name); return; } if (left->type != node->right->type) { error(node->line, "类型不匹配：%s 是 %s，右值是 %s", node->left->name, type_name(left->type), type_name(node->right->type)); } }

逻辑说明：lookup_symbol在当前作用域链里找变量，找不到就报未声明。node->right->type是表达式类型推导的结果，比如a + b的类型由a和b中较宽的类型决定。参数说明：error函数接收行号和格式化字符串，输出到stderr并记录错误数量。注意类型检查要在所有表达式节点上递归调用，不能只查顶层赋值，否则a = b + c里b和c类型不匹配就漏掉了。

2.3 四元式生成：临时变量与回填

中间代码用四元式(op, arg1, arg2, result)表示，比如a = b + c生成(+, b, c, t1)和(=, t1, -, a)。临时变量用t1, t2, ...递增命名。难点在控制流：if (a < b) stmt1 else stmt2需要生成条件跳转和标签，而while循环需要回填跳转地址。常见做法是维护一个标签栈，遇到if时生成(j<, a, b, L1)，然后生成stmt1的四元式，再生成(j, -, -, L2)跳过stmt2，最后回填L1和L2的位置。回填的意思是，生成跳转指令时目标标签还没确定，先留空，等标签确定后再把四元式里的目标地址填上。

// codegen.c 片段：if-else 的四元式生成与回填 void gen_if(ASTNode *node) { int label_else = new_label(); int label_end = new_label(); gen_expr(node->cond); emit("j<", node->cond->result, "0", label_else); // 条件为假跳else gen_stmt(node->then_branch); emit("j", "-", "-", label_end); backpatch(label_else, next_quad_index()); // 回填else标签 gen_stmt(node->else_branch); backpatch(label_end, next_quad_index()); // 回填end标签 }

逻辑说明：new_label()返回一个唯一标签号，emit生成一条四元式并返回索引，backpatch把之前留空的跳转目标填成当前四元式索引。参数说明：node->cond->result是条件表达式生成的临时变量或变量名。注意j<的语义是“小于则跳转”，所以条件为假时跳label_else。如果条件表达式是a >= b，需要先转换成!(a < b)或者生成j>=指令，具体看课设要求。血泪经验是：回填顺序不能乱，先回填else再生成else分支，最后回填end，否则跳转地址会指到错误的位置。

3. 部署文档里没写的环境配置与编译链路

3.1 从源码到可执行文件的完整命令

部署文档通常只写“运行make即可”，但实际环境里缺库、缺头文件、路径不对是常态。我一般会先看Makefile里的CFLAGS和LDFLAGS，确认有没有依赖flex、bison、llvm。同济课设的参考实现多数是纯C，不依赖外部库，所以gcc -o compiler *.c就能编译。但如果源码里用了readline做交互式输入，就需要-lreadline。下面是一个典型的编译命令序列，假设源码在src/目录，头文件在include/，测试用例在tests/。

# 编译类C编译器 gcc -Iinclude -Wall -g -O0 src/lexer.c src/parser.c src/sema.c src/codegen.c src/main.c -o compiler # 运行测试用例 ./compiler tests/test1.c > tests/test1.ir # 查看四元式输出 cat tests/test1.ir

逻辑说明：-Iinclude告诉gcc头文件路径，-Wall打开所有警告，-g保留调试信息，-O0关闭优化方便调试。参数说明：-o compiler指定输出文件名。注意如果源码里有#include "lexer.h"，而lexer.h在include/下，就必须加-Iinclude，否则报“找不到头文件”。常见坑是Makefile里用了gcc -c生成.o再链接，但.o文件没清理干净，导致改了代码后链接的还是旧目标文件，行为诡异。我一般会先make clean再make。

3.2 测试用例的设计与预期输出

课设验收通常会给几个测试用例，但自己得准备更全的。我一般会写五个层次的测试：第一层只有int main() { return 0; }，验证词法和语法基本通路；第二层加变量声明和算术表达式，验证符号表和四元式生成；第三层加if-else，验证跳转和回填；第四层加while，验证循环回填；第五层加函数定义和调用，验证参数传递和返回地址。每个测试用例的预期输出要手动算一遍四元式，比如a = 1 + 2 * 3应该生成(*, 2, 3, t1)、(+, 1, t1, t2)、(=, t2, -, a)。如果编译器输出顺序不对，说明表达式求值的优先级处理有问题。

表格说明：四元式数量是估算，具体取决于表达式复杂度。常见错误里“跳转标签回填错位”最隐蔽，因为编译器不报错，但生成的中间代码执行结果不对。排查方法是把四元式打印出来，手动模拟执行，看跳转目标是不是指向了正确的标签。

3.3 跨平台编译的注意点

如果部署文档说“支持Windows和Linux”，那大概率用了条件编译。Windows下gcc通常是MinGW，头文件路径用\，而Linux用/。我一般会在Makefile里用$(OS)判断，或者直接用CMake。但课设源码多数是手写Makefile，所以跨平台时要注意：unistd.h在Windows下没有，readline在MinGW里要单独装。如果源码里用了fork()或popen()，Windows下直接编译失败。常见做法是加#ifdef _WIN32宏，把系统相关调用替换成Windows API。但课设通常不要求跨平台，所以如果部署文档写了“支持Windows”，先确认是不是只支持WSL或Cygwin。

4. 避坑与排查：课设验收前必须过的五道坎

4.1 词法分析把关键字识别成标识符

现象：输入while (i < 10) { i = i + 1; }，语法分析报“期望标识符但得到while”。原因：词法分析的关键字表没包含while，或者查表时大小写敏感但输入是大写WHILE。解决：在parse_identifier里，先查关键字表，命中就返回对应token类型，否则返回TOKEN_ID。关键字表用静态数组或哈希表都行，注意int、if、else、while、return这几个必须覆盖。

4.2 语法分析左递归导致栈溢出

现象：解析a = b = c时程序崩溃或死循环。原因：赋值表达式的文法写成了expr -> expr = expr，这是左递归，递归下降会无限调用自己。解决：改成右递归或迭代，比如assign -> ID = assign | expr。或者用循环处理连续赋值，先解析一个表达式，如果下一个token是=，就继续解析右边的表达式，生成四元式时从右往左结合。

4.3 符号表作用域没清理导致重复定义

现象：两个函数里都有int i;，第二个函数报“变量i重复定义”。原因：符号表是全局的，没有在进入新函数时清空或压栈。解决：每个函数维护一个独立的符号表，或者用作用域栈，进入函数时push_scope()，退出时pop_scope()。查找时从栈顶往下找，找到就返回。注意函数名本身要插在全局作用域，否则递归调用找不到自己。

4.4 四元式临时变量命名冲突

现象：嵌套表达式a = (b + c) * (d + e)生成的四元式里，两个中间结果都叫t1。原因：临时变量计数器没有全局递增，或者每个表达式生成时重置了。解决：用一个全局变量temp_count，每次new_temp()就temp_count++并返回t{count}。注意不要用局部变量做计数器，否则递归调用时会重复。

4.5 回填时标签地址指向错误

现象：if-else生成的中间代码执行时，不管条件真假都走else分支。原因：backpatch填的地址是四元式索引，但跳转指令的目标应该是标签对应的索引，而标签是在生成分支代码后才确定的。解决：维护一个标签到索引的映射，backpatch时把跳转指令的result字段改成标签索引。注意j指令的语义是“无条件跳转到result”，j<是“小于则跳转到result”，不要搞反。

5. 进阶技巧：用AST可视化快速定位语义错误

课设验收前，如果四元式输出不对，最有效的调试手段不是盯着代码看，而是把AST打印出来。我一般会写一个print_ast函数，用缩进表示层级，每个节点打印类型和值。比如a = b + c * d的AST是Assign(a, Add(b, Mul(c, d)))，一眼就能看出优先级对不对。如果AST错了，四元式肯定错；如果AST对了但四元式错，问题就在代码生成阶段。下面是一个简单的AST打印实现，用递归加缩进。

// ast.c 片段：带缩进的AST打印 void print_ast(ASTNode *node, int depth) { if (!node) return; for (int i = 0; i < depth; i++) printf(" "); switch (node->type) { case AST_ASSIGN: printf("Assign(%s)\n", node->left->name); print_ast(node->right, depth + 1); break; case AST_ADD: printf("Add\n"); print_ast(node->left, depth + 1); print_ast(node->right, depth + 1); break; case AST_MUL: printf("Mul\n"); print_ast(node->left, depth + 1); print_ast(node->right, depth + 1); break; case AST_ID: printf("Id(%s)\n", node->name); break; case AST_NUM: printf("Num(%d)\n", node->value); break; default: printf("Unknown\n"); } }

逻辑说明：depth控制缩进，每进一层多两个空格。AST_ASSIGN先打印左值名字，再递归打印右值表达式。AST_ADD和AST_MUL分别打印操作符和左右子树。参数说明：node->name是标识符名字，node->value是数字字面量。注意打印顺序要和求值顺序一致，比如Add先打印左子树再打印右子树，这样能看出结合性。如果打印出来是Add(Mul(c, d), b)，说明语法分析把b + c * d解析成了(b + c) * d，优先级处理反了。

另一个进阶技巧是给四元式加行号注释。在emit函数里，把当前解析的行号作为注释附加到四元式后面，比如(+, b, c, t1) // line 5。这样当中间代码执行结果不对时，能快速定位到源码的哪一行。我一般会在Token结构体里保存行号，语法分析时把行号传到AST节点，代码生成时从AST节点取行号。这个习惯在调试复杂嵌套表达式时特别有用，因为四元式本身不包含源码位置信息，没有行号就只能靠猜。

最后说一个验收时的习惯：把编译器的输出重定向到文件，然后用diff和预期输出对比。如果预期输出是手动算的，先确认手动算的没错。我见过有人手动算错了四元式，然后改编译器去迎合错误答案，越改越乱。正确做法是先写一个最简单的测试用例，比如int main() { int a; a = 1; return a; }，手动算出四元式，确认编译器输出一致，再逐步加复杂度。这样每加一个特性，都能快速定位是哪一层出了问题。希望帮到你。

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