简介这是一份重庆大学编译原理课程实验项目资源包目标是从零构建一个轻量级RISCV编译器适合正在学习编译原理、需要完成课程设计或希望深入理解编译器实现的学生与开发者。压缩包共87个文件约1.56MB内含CMake与Makefile脚本、C/C源码与头文件、编译生成的.o/.a/.bin文件并附实验指导书PDF、README及许可说明便于理清工程结构并快速复现实验。编译过程按前端、中端、后端组织覆盖词法分析、语法分析、语义分析、中间代码生成、代码优化和RISCV目标代码生成等关键环节同时参考了ScienceLi1125的CQU-Stu开源项目可作为课程实验完整参考实现。目前已有59人学习对于想借助完整工程样例打通编译原理理论到代码实现的学习者是一份值得对照动手的资源既能巩固编译前端知识也能体会后端优化与目标代码生成的设计思路。1. 手搓一个 RISC-V 编译器课程实验的难点从来不在“写代码”把别人的课程设计源码摊开、复制粘贴编译一过就以为自己懂了——这是编译原理课程实验里最典型的翻车姿势。这个标题真正要做的事不是让你把 CQU-Stu.zip 里的代码抄一遍而是借它的工程边界自己搭一个从 C 子集到 RISC-V 汇编的轻量级编译器词法分析、语法分析、中间代码、指令选择、目标代码生成每一层都亲手过一遍。它能解决的问题是把编译器这个黑匣子从“课上学过”变成“我能复现”适合正在赶编译原理课程设计、或者想往工具链方向走一步的人。下面从参考项目的拆解开始一路讲到 RISC-V 汇编生成的具体细节和调试时的血泪经验。2. 先拆 CQU-Stu.zip 这类参考项目读报告比读代码先走一步2.1 课程设计参考工程的常规构成先分清“可借鉴”和“不能抄”很多同学拿到 CQU-Stu.zip 的第一反应是进 src 目录读源码。这个顺序其实是反的。类似这样的课程设计参考工程普遍会包含四类东西说明文档README 或实验报告正文、编译器源码、测试用例、构建脚本Makefile 或 CMakeLists。说明文档里往往写着整个工程的边界目标指令集是哪一档、输入语言是 C 的哪个子集、评分点在哪里。先读文档等于先拿到地图直接从源码开始读很容易陷进某个函数的细节出不来。我一般会按下面的顺序快速摸清一个参考工程这个顺序同样适用于你手上任何一个课程设计参考包先看 README 或实验报告里的“运行方法”找到构建命令。能复现构建才有资格谈后来的一切。找到“语言定义”或“支持语法”小节确认输入语言边界。这决定了你后面递归下降要覆盖多少种语句。找到“目标平台”或“指令集”说明确认是 RV32I 还是带了 M/C 扩展。课程编译器通常只做 RV32I。最后再打开 src先看目录结构不看函数实现。目录结构暴露模块划分。提示如果参考工程没有 README 只有报告报告就是设计文档。编译原理课程的实验报告通常要求写设计思路、模块划分和测试截图这些内容恰好能帮你理解作者为什么要这么拆模块。2.2 读参考工程先读 C 子集定义裁剪过的语法才是你的需求文档完整 C 语言的语法规模是一份课程设计做不完的。所以这类工程第一步必然是裁剪 C 子集留下最核心的类型、语句和表达式砍掉结构体、共用体、switch、goto 这类扩展语法。参考工程的 C 子集列表实际上就是你的语法分析器的工作边界也是你写测试用例的输入契约。常见的 C 子集会包含类型int、char最多加指针和一维数组语句表达式语句、复合语句花括号块、if-else、while、for、return表达式算术、关系、逻辑、赋值、函数调用、数组下标不支持struct/union、switch、goto、宏、预处理指令。这里有个很实际的提醒子集越小越好做但老师评分的测试用例往往踩在子集边界上。比如边界是“支持一维数组”那测试就极可能有a[i] a[j] 1这样的用例如果边界是“支持指针”那*p的解引用和取地址肯定会考。读子集定义时要把每个“支持”都当成一个必须实现的功能点而不是一个名词。另一个常见误解是把“C 子集”当成 C 语言本身来写。比如语法分析器里写了完整的表达式优先级表却漏了数组下标的代码生成或者把char当int的完全等价类型处理没有在赋值时做截断导致 char 变量存进去再读出来变成一个大整数。子集定义里没写“char 需要符号扩展还是零扩展”但数组和函数传参里 char 的存储宽度恰恰是后面最容易踩的坑。2.3 参考代码的正确使用方式借架构不借实现课程设计参考工程的正确打开方式是把它的模块划分和接口设计当作骨架把每个模块的内部实现换成你自己的。“参考”和“复制”的界限就在这里模块边界词法→语法→中间代码→目标代码是可以借鉴的因为这是编译器的经典结构任何一本教材都会这么画但某个具体函数怎么写、某个边界条件怎么处理一定要自己写出来。能借的是这几样目录/模块划分、四元式的字段定义思路、栈帧布局策略、测试用例的组织方式。不能借的是词法扫描的主循环、递归下降的解析函数、符号表的插入和查找逻辑、指令选择的 switch 分支——这些是课程检查“你是否自己完成”的重点区域。如果你参考的工程用了 flex/bison 生成器而你选择手写递归下降解析器这是完全合理的差异化。生成的解析器代码几乎不可读也很难在答辩时讲清楚每一步在做什么手写解析器虽然代码行数多一些但每个函数对应一种语法结构讲起来是“一对一”的老师追问时你能答得上来。反过来说如果你参考的工程本身就是手写的那你的重点就放在指令选择、栈帧布置这些材料上不要在解析器上跟它做出一模一样的东西。编译器和编辑器的本质区别也在这里编辑器只是修改文本文件编译器要把文本翻译成语义等价的另一门语言。参考工程提供的是一套翻译流程的设计而不是一套可以原样套用的文本处理模板。3. 搭建最小流水线从 C 子集语法树到三地址码3.1 手写词法分析还是 flex/bison轻量级项目我选递归下降先回答问题为什么轻量级编译器我一般建议手写而不是上 flex bison。第一轻量级项目的 token 种类很有限标识符、数字、字符串、关键字、运算符、括号和分隔符手写 Scanner 全代码也就两三百行。第二手写解析器能做到语法分析与中间代码生成同步进行一边识别一边发射四元式不需要先把整棵 AST 建完再遍历。第三生成器产物里的 yylex/yyparse 全局状态和冲突报告对新手排查不友好你可能花了半天在调 bison 的移进归约冲突而手写版本遇到同类问题是直接可以在代码里断点定位的。手写词法分析器的核心是一个扫描循环跳过空白和注释遇到引号处理字符串字面量遇到数字读完整组数字遇到字母或下划线读关键字/标识符否则按运算符表匹配。下面是一个最小 Scanner 的核心接口用 C 写enum class TokenType { INT_LIT, IDENT, KEYWORD, OP, LPAREN, RPAREN, LBRACE, RBRACE, SEMI, END }; struct Token { TokenType type; std::string text; // 字面量或标识符名称 int intVal; // INT_LIT 时使用 int line; // 报错定位用 }; class Scanner { public: explicit Scanner(const std::string src) : src_(src), pos_(0), line_(1) {} Token next(); // 每次返回一个 token private: void skipWhitespaceAndComments(); char peek() const { return pos_ src_.size() ? src_[pos_] : \0; } char advance() { char c src_[pos_]; if (c \n) line_; return c; } std::string src_; size_t pos_; int line_; };这个接口的关键设计是next()每次只消费一个 token。Parser 需要几个就看几个不会把整个 token 流预先存在内存里这既省内存也天然支持“语法分析边扫描边生成”的流水线方式。peek()和advance()两个私有方法是核心peek只看不消费advance消费并维护行号。行号必须维护否则测试用例一报错你就得对着汇编数行数那是灾难。参数说明intVal只在INT_LIT时有效字符串字面量统一放进text。关键字表单独放在一个std::unordered_mapstd::string, TokenType里扫描到 IDENT 后再查表决定是关键字还是普通标识符。这是比“每读一个字符就判断关键字”来得更清晰的常见做法。3.2 中间表示选三地址码四元式结构定义与生成时机中间表示可以选 AST、三元式、四元式、SSA但课程编译器的最佳选择是三地址码Three Address CodeTAC落成四元式存储。理由很直接RISC-V 指令本身就是三操作数格式add rd, rs1, rs2。四元式与汇编之间存在近乎一对一的对应关系寄存器分配和指令选择都省事。相比之下 AST 直接生成汇编要把“表达式树求值顺序”这样的逻辑重复处理SSA 则要处理 phi 节点课程编译器用不上。一个最小四元式结构如下enum OpKind { ASSIGN, ADD, SUB, MUL, DIV, NEG, LABEL, GOTO, IFZ, IFNZ, CALL, RET }; struct Quad { OpKind op; std::string arg1; // 第一操作数可能是常量、变量名或临时变量名 std::string arg2; // 第二操作数单目运算时为空 std::string res; // 结果变量名、临时变量名或跳转标签 };以a b c * d为例生成的四元式序列是t1 c * d a b t1临时变量统一命名成t1, t2, ...由计数器生成。注意这里不做任何优化时每出现一个运算就产生一个新临时变量符号表里会堆出一堆tN。这是正常的后面的常量折叠章节会处理一部分无用的tN。四元式生成时机是语法分析期间递归下降解析到赋值语句的右值表达式时每归约出一个二元运算立即发射一条四元式不需要把 AST 存下来。这个“边解析边发射”是手写解析器和生成器产物最大的行为差异之一。递归下降解析表达式时优先级不靠查表靠的是解析函数的层级嵌套。加减在最外层乘除在内层括号和因子在最底层。每个层级解析完返回一个操作数变量名或临时变量名上层拿到左右操作数后发射一条四元式结果作为新的操作数继续往上参与运算。这套做法的好处是代码生成顺序和表达式求值顺序完全一致调试时对着四元式能直接看出优先级处理得对不对。3.3 一个最小样例从 C 代码到四元式的完整走查用一个最简单的非叶子函数走一遍。输入int max(int a, int b) { int r; if (a b) r a; else r b; return r; }期望生成的四元式序列按发射顺序// 表达式 a b t1 a b // 关系比较结果0 或 1 IFZ t1 GOTO .Lelse r a GOTO .Lend .Lelse: r b .Lend: RET r几个值得注意的地方第一a b被当作一个普通二元运算结果放进临时变量t1然后用IFZ t1 GOTO做条件跳转。这是“把条件归约为值”的思路比较本身是表达式分支才是语句。第二r a和r b之间必须插一个无条件跳转GOTO .Lend否则 then 分支执行完会落入 else 分支。这个GOTO是最容易丢的写 if-else 代码生成时只记得发射 then 分支忘了在 then 末尾发射跳过 else 的跳转。第三标签.Lelse和.Lend在汇编层要保证唯一工程上常见做法是给标签加函数名前缀比如max.Lelse避免多个同名函数生成重名标签。这一步虽然发生在四元式层但命名规范要提前定好否则汇编器先替你把错找出来。这个样例看起来简单但它同时覆盖了条件分支、基本块末尾的无条件跳转和 return 的传值是做目标代码生成之前一个可靠的中间检查点。建议你拿到参考工程后先不急着跑全流程而是拿这个 max 函数验证你自己的四元式输出是否与预期一致再做下一步寄存器分配与汇编生成。4. 生成 RISC-V 汇编寄存器约定、栈帧布局与函数调用现场4.1 RV32I 寄存器约定表调用者保存与被调用者保存的边界轻量级编译器一般锁定 RV32I 基础整数指令集这是 RISC-V 里指令条数最少的一档没有乘法除法扩展M 扩展时乘除要通过移位和加减法合成。课程编译器通常会选择 RISC-V 官方 psABI 里规定的那套寄存器约定。这张表必须背下来因为寄存器分配和函数调用都依赖它寄存器ABI 名称用途谁负责保存x0zero常量 0无需保存x1ra返回地址调用者实际由被调函数保存x2sp栈指针无需保存x8s0/fp保存寄存器/帧指针被调用者保存x5-x7, x28-x31t0-t6临时寄存器调用者保存x10-x17a0-a7参数/返回值调用者保存x8-x9, x18-x27s0-s11保存寄存器被调用者保存翻译成人话就是你的函数想用s0-s11里任何一个寄存器必须在入口压栈、返回前恢复用完t0-t6或a0-a7不用恢复但你要清楚这些值在调用别的函数之后可能已经被改掉。课程编译器最常见的简化是把“跨调用存活”的变量全部放在栈帧里寄存器只承担表达式求值的临时结果。虽慢但正确而且实现量最小。4.2 栈帧布局偏移量错一位所有局部变量一起串号RISC-V 栈从高地址向低地址增长sp栈指针永远指向当前栈顶。一个函数的栈帧从高到低通常是这么排的内容相对 fp 偏移说明调用者栈帧...高地址返回地址 rafp-4非叶子函数必须保存旧帧指针 fpfp-8使用帧指针时保存局部变量区fp-12 往下按变量声明顺序或按活跃区间分配临时变量/逃逸变量更低的地址寄存器不够或跨调用存活的值落在这里参数区可选栈帧底部被调函数参数超过 a0-a7 时如果你的函数内部只修改 sp 一次在 prologue 里也可以不用帧指针局部变量统一用sp 偏移访问。但一旦你在函数体里为调用子函数再次调整 sp比如压参数所有基于 sp 的偏移就全乱了。课程编译器实现里我建议引入帧指针 fp代价只是多保存一个寄存器换来的是所有局部变量有一个稳定的基准地址调试时省一大半心。注意ABI 要求 sp 在任意时刻 16 字节对齐分配栈帧时要把局部变量总大小向上取整到 16 的倍数不然调用外部库函数时可能触发非对齐访问。4.3 一个递归函数的完整汇编模板fact(n) 的 prologue 与 epilogue直接看例子。递归函数的 prologue/epilogue 是所有函数里最完整的它覆盖了保存 ra、保存 fp、保存参数、调用子函数、恢复现场五件事。输入int fact(int n) { if (n 1) return 1; return n * fact(n - 1); }对应的汇编模板RV32I乘法按 RV32IM 处理fact: addi sp, sp, -16 # 分配 16 字节栈帧保持 16 字节对齐 sw ra, 12(sp) # 保存返回地址 sw s0, 8(sp) # 保存调用者的帧指针 addi s0, sp, 16 # 建立当前帧指针 sw a0, 4(sp) # 参数 n 存入栈帧用于跨调用访问 # if (n 1) return 1; lw t0, 4(sp) # t0 n li t1, 1 bgt t0, t1, .Lrecurse li a0, 1 j .Lreturn .Lrecurse: # 准备调用 fact(n - 1) lw t0, 4(sp) # t0 n重新从栈加载t0 跨调用不可靠 addi t1, t0, -1 # t1 n - 1 mv a0, t1 # 传给子调用的参数放入 a0 jal fact # 子调用这会覆盖 t0/t1/a0 lw t1, 4(sp) # t1 n再次从栈加载 mul a0, t1, a0 # a0 n * fact(n - 1) .Lreturn: lw ra, 12(sp) # 恢复返回地址 lw s0, 8(sp) # 恢复帧指针 addi sp, sp, 16 # 释放栈帧 ret这段代码有几个必须盯住的点。第一jal fact会覆盖 ra也会随意改写 t0/t1/a0所以在子调用之后n不能继续留在寄存器里必须每次从栈帧重新 load。第二mul a0, t1, a0把子调用的返回值 a0 和刚加载的 n 相乘结果直接放进 a0 作为本层返回值——这一步没有任何多余的寄存器保存。第三栈帧分配的大小 16 是 4 个字的整数倍且满足 16 字节对齐如果只保存 ra、s0、n 三个字12 字节也要向上取整到 16。这是 ABI 的硬性要求。如果你用的目标平台没有 M 扩展那个mul要替换成移位加法的序列比如循环累加课程编译器一般可以声明“目标平台为带 M 扩展的 RV32IM”用mul指令即可。到底用哪一档要跟参考工程的说明一致否则拿去板子上跑会碰到非法指令异常。4.4 数组与指针的地址计算base index * scale 是第一个大坑C 子集里如果支持一维数组数组元素地址的计算是所有代码生成里最容易写错的。对于a[i]汇编层要做的只有一件事把“a 的基址栈帧偏移”、“i 的值”、“元素类型大小”三者做一次乘加。以 int 数组为例scale 是 4# 假设 a 的基址在栈帧里的偏移是 -20相对 fp # i 的值在 t0结果地址放入 t1 lw t0, ... # t0 i slli t1, t0, 2 # t1 i * 4 addi t2, fp, -20 # t2 a 的基址 add t1, t1, t2 # t1 a[i] lw t0, 0(t1) # t0 a[i]slli t1, t0, 2是左移两位等价于乘 4这是编译器应做的强度削减。如果你支持的元素类型还有 charscale 1那slli这一行就省略。这里最容易犯的错是把 scale 写死为 4结果char a[10]也会按 4 字节步长去取访问越界但不报错——这类错误运行时不崩只在拿到错误值后表现为“玄学”。所以符号表里类型大小这个字段必须在语义分析阶段就把每个变量的大小算好而不是到生成汇编时再根据 token 内容临时判断。*p的翻译与数组下标是同一套机制先算 p 的值再以它作为地址 load只是基址来自寄存器而不是栈帧偏移。5. 避坑与排查为什么你的编译器编译通过但运行结果全错5.1 函数返回后局部变量被“偷偷改掉”跨调用的寄存器冲突现象main 里调用了一个函数后main 自己的某个局部变量值变了打印出来是个大整数或上一次的旧值。原因你的代码生成器把局部变量分配到了寄存器比如 t0然后在调用子函数之前没有把这个寄存器压栈。子函数内部的临时变量使用 t0 把它覆盖了。RISC-V 的 t 寄存器是调用者保存的语义上“调用者要用就自己保存”编译器没做这个保存动作。解决课程编译器最稳妥的寄存器策略是所有跨调用存活的变量一律不进寄存器从符号表到汇编都只给它们栈帧偏移。访问时 load、写完 store。临时变量才允许用 t0-t2并且在使用前要确认上一个值已经用完了。排查时对着汇编看每个跳到jal之前有没有把之后还要用的值压栈。提示如果你后续打算把编译器输出接到裸机环境编译运行比如 CH32V 这类 RISC-V 单片机中断函数和普通函数的寄存器保存约定是另一套逻辑——课程阶段先不要往这个方向扩展把普通函数的 jal/ret 现场做对已经是这一章的及格线。5.2 if/else 配对错乱悬垂 else 的经典翻车现场现象if (a) if (b) c 1; else c 2;这段代码预期 else 挂在if (b)上实际却挂到了if (a)上导致 a 为假时 c 反而被赋值成 2。原因递归下降解析 if 语句时解析完内层 if 的语句体后直接把控制权交还给外层没有让“内层 if 吃掉它后面的 else”。C 语言标准规定 else 与最近的未匹配 if 结合这个规则在递归下降里要落实成解析内层 if 时先解析它的 then 分支和 else 分支再把整个 if 语句作为外层 if 的 then 分支返回。解决写 if 语句解析时用递归结构天然处理“最近匹配”Stmt parseIf() { expect(IF); expect(LPAREN); Expr cond parseExpr(); expect(RPAREN); Stmt then parseStmt(); // 递归进入内层else 会在内层被消费 Stmt els nullptr; if (peek() ELSE) { advance(); els parseStmt(); } return makeIf(cond, then, els); }关键在于parseStmt()的递归内层 if 自己会调用 parseIf 并消费完自己的 else外层 if 拿到的 then 分支已经是“不含 else 的完整 if 语句”。排查这个问题的快速方法是把解析器的递归深度打出来看每个 else 被哪个层级的 parseIf 消费。用 flex/bison 做这个功能时则注意 bison 对悬垂 else 的移进归约冲突会默认采用“移进”这恰好是 C 的语义不要因为看到 conflict warning 就去改文法优先级结果反而改错。5.3 数组访问到奇怪的值偏移计算把类型大小漏了现象int a[10]访问 a[3]拿到的值看起来像 a[1] 或完全无关的数据程序不崩溃只是结果不对。原因常见两种。一把每个元素按 1 字节计算偏移a[3] 实际访问了从基址偏移 3 字节的位置正好落在 a[0] 的中间二数组基址取自变量名错误的栈帧偏移比如取了变量 a 的地址本身而没有考虑符号表里数组分配在栈帧的起始偏移。解决统一封装一个“地址生成”函数输入是数组基址、下标表达式、元素大小输出是汇编序列。int 用slli移位乘 4char 直接加下标。写完后用一组连续下标a[0], a[1], a[2], a[3]对着生成的汇编逐个手算一遍地址。不要只跑一次完整程序就认为数组支持没问题——地址对的整数访问放在不同上下文里仍然可能在偏移上出细微偏差。5.4 条件跳转方向写反跑成死循环先看 beq/bne 极性现象一个 for 循环条件明明写着 i 10生成的程序要么一次都不进循环要么永远出不来。原因条件跳转和目标跳转的方向搞反了。比如“条件成立则跳过循环体”实现成了“条件不成立跳过循环体”或者 IFZ/IFNZ 与 beq/bne 对应关系弄反。这类错误编译器自己不会报错四元式层看起来也对错在最后的指令选择。解决在指令选择器里只保留一种固定的映射约定比如四元式IFZ t1 GOTO L表示“t1 为 0 则跳转 L”对应汇编beq t1, x0, LIFNZ t1 GOTO L对应bne t1, x0, L。全部代码生成遵循这一套不要在某个分支里用取反的写法“图省事”。排查方法找到循环退出条件的四元式人工翻译一遍期望汇编再对比生成结果先确认中间表示再往下看指令选择两级对照能定位到具体是哪一层写反。5.5 编译大文件时“堆空间不足”词法分析器别把整个 token 流挂在内存现象小的测试用例一切正常换成几千行的测试文件后编译器进程崩溃报 bad_alloc 或者段错误。原因词法分析器把整个源文件一次性解析成 token 数组保存在 std::vectorToken 里语法分析再从头遍历。这个设计在文件规模变大后内存翻倍增长如果四元式和符号表也都驻留在内存堆空间不足只是时间问题。解决把 Scanner 的next()设计为“按需读取”Parser 需要什么 token 才向 Scanner 要一个最多保留一个回看 token。这样无论源码多大内存里同时存在的 token 只有两个四元式才是占内存的主体。如果你的参考工程本身就是全量 token 流的设计自己在做的时候改成惰性读取这个改动不大但收益明显。另一个常见元凶是 AST 节点用new分配后没有释放边解析边发射四元式的实现不需要保留整棵 AST解析函数返回后节点即可回收。6. 给编译器加一个能进答辩的优化三地址码上的常量折叠课程评分表上“代码优化”这一栏最稳的得分点不是寄存器分配也不是循环优化而是一个十几行的常量折叠。它无副作用折叠前后的程序语义完全一致不会引入新 bug而且能直接体现在生成汇编的行数上答辩时拿得出对比数字。做法是在四元式生成之后再多遍历一遍。遇到“操作数都是字面量”的算术四元式直接计算结果并替换成一条赋值for (auto q : quads) { if (isIntConst(q.arg1) isIntConst(q.arg2) isArithOp(q.op)) { int v eval(q.op, std::stoi(q.arg1), std::stoi(q.arg2)); q.op ASSIGN; q.arg1 std::to_string(v); q.arg2 ; } }这段代码的关键不是算法而是时机折叠要发生在四元式层不是在汇编层。汇编层的伪指令已经展开、临时变量已经映射到寄存器再做常量折叠只能改立即数合并机会全错过了。配合一个更简单的常量传播——如果一个变量整个函数里只被赋值一次且赋的是常量把这个值复制到所有使用点——能把int x 3; y x * 5;直接折成y 15。这两个加起来不到四十行但对只做基础要求的课程编译器来说已经算“做了优化”。验证方法也简单用 fact(10) 之类的递归程序对比优化前后的汇编行数再把统计写进实验报告的“优化效果”小节。如果老师追问什么是强度削减就从常量折叠往上再补一个把乘 2 的幂替换成移位同样在四元式层做。说句题外话我做课程设计那阵子第一次优化的冲动是把目标代码生成里的乘法全改移位结果因为没考虑负数右移的符号位问题翻车翻了一整晚。后来养成一个习惯所有优化都先做在中间表示上再往下走因为中间表示可读、可回退比在汇编里打补丁要爽得多。这个习惯一直到后面做工具链方向都没改。希望帮到你。本文还有配套的精品资源点击获取
