尧图网站建设 
简介编译原理课程设计类C语言编译器完整资料包面向计算机专业学生编写编译器课程项目提供从界面编辑到目标代码生成的整套实现。程序支持代码行号、关键字与变量高亮、注释区分与自动补全并能完成词法、语法、语义分析及中间代码优化输出汇编文件和详细编译日志覆盖词法符号串、LR(1)分析表、语法树、符号表、中间代码优化等关键环节。压缩包共104个文件、约25.63MB内含8个C源文件与7个头文件源码、Qt运行库dll、界面截图png、exe可执行程序、pro工程文件及说明文档目录结构便于按模块研读。已有582人学习下载。借助这些资料读者可对照源码与运行效果逐步理解编译原理各阶段的实现细节也可将图形编辑器、分析算法与界面交互方式迁移到自己的课程设计项目中。1. 类C编译器课程设计把形式语言从纸上变成能跑的程序课程设计拿到“类C语言编译器”这个题最迷惑人的地方在于老师要的不是你发明一门新语言而是你把《编译原理》教材里的词法分析、语法分析、语义分析、中间代码生成这几章从纸上的状态转移图和产生式变成一份能打开就跑的源代码和一套能对得上号的文档说明。真正折磨人的是“边界”问题——整数和浮点要不要都支持、数组要不要带下标、函数返回值要不要做类型检查……边界划多了做不完划少了答辩时一句“你这个 if 和 while 嵌套怎么一跑就崩”就把你问住。我按课程设计的常见配置做过类似方案这篇把设计路线、核心代码骨架和最常见的翻车点按顺序讲清楚适合正在赶课设的学生以及想快速拿下一套可用原型的初级开发者。读者最好有 C 基础和一点数据结构知识没有也不影响跟着抄就行。2. 类C语言子集与文法设计先定边界再写 parser2.1 语言子集的取舍类型、语句与控制流的最小可用集动手写代码前第一件事是把“类C”这三个字翻译成一张能力清单。我知道很多同学第一步就去写词法分析结果 token 都切完了才发现文法里没有 for 循环或者函数参数列表没法表达整个设计推倒重来。常见做法是先明确子集范围再写文法最后才碰代码。我一般会这样划边界既能覆盖编译原理的主要考点又能在两周内做完类型int、float加一个 void 用于函数返回值。char 看起来简单实际牵扯到字符串常量和转义字符课设优先级低。语句变量声明、赋值、表达式语句、if-else、while、return。for 可以在有富余时间时加不加不扣分因为 for 可以等价改写为 while。表达式四则运算、比较运算、逻辑运算、||、!支持小括号改变优先级。数组和指针这类复杂类型放到扩展项。函数支持参数列表、递归调用、返回值。不支持函数重载和默认参数。全局变量支持全局声明但不支持跨文件编译所有代码放一个源文件。按这个清单文法可以写成下面这份 baseline后面 parser 和 AST 全都围绕它展开program : decl_list decl_list : decl decl_list | ε decl : type ID ( params ) compound_stmt type : int | float | void params : param_list | ε param_list : param , param_list | param param : type ID compound_stmt : { var_decl_list stmt_list } var_decl_list : var_decl var_decl_list | ε var_decl : type ID ; stmt_list : stmt stmt_list | ε stmt : var_decl | expr_stmt | if_stmt | while_stmt | return_stmt | compound_stmt expr_stmt : expr ; if_stmt : if ( expr ) stmt | if ( expr ) stmt else stmt while_stmt : while ( expr ) stmt return_stmt : return expr ; | return ; expr : additive_expr | expr || additive_expr additive_expr : mul_expr | additive_expr mul_expr | additive_expr - mul_expr mul_expr : unary_expr | mul_expr * unary_expr | mul_expr / unary_expr这份文法里我故意埋了一个坑表达式那几条是左递归的后面写递归下降时要去掉。你现在只需要做的就是把这份文法放进课设文档的“语言定义”章节作为需求基线。文档里建议再画一张表列出“本子集支持 / 扩展项 / 明确不支持”答辩老师一眼就能看出你是思考过边界的而不是胡写一通。2.2 词法分析手写 tokenizer 的关键分支与数字解析陷阱子集定了词法分析就能写了。常见做法有两种用 flex 生成或者手写。课程设计我强烈建议手写因为 flex 生成的是黑匣子答辩被问“你这个状态转移图怎么对应到代码”时很难答。手写一个 tokenizer 也就 200 行左右而且是纯粹的机械活。先定义 token 类型enum class TokenType { IDENT, // 标识符 INT_LIT, // 整型字面量int FLOAT_LIT, // 浮点字面量 KW_INT, KW_FLOAT, KW_VOID, KW_IF, KW_ELSE, KW_WHILE, KW_RETURN, PLUS, MINUS, STAR, SLASH, ASSIGN, EQ, NEQ, LT, GT, LE, GE, AND, OR, NOT, LPAREN, RPAREN, LBRACE, RBRACE, SEMI, COMMA, END }; struct Token { TokenType type; std::string lexeme; double numVal; // 字面量的数值统一用 double 存 int lineNo; // 报错定位用 };然后实现核心的扫描函数std::vectorToken tokenize(const std::string src) { std::vectorToken tokens; size_t i 0, line 1; while (i src.size()) { char c src[i]; // 空白与换行 if (isspace(c)) { if (c \n) line; i; continue; } // 注释// 到行尾或 /* ... */ if (c / i 1 src.size() src[i 1] /) { while (i src.size() src[i] ! \n) i; continue; } if (c / i 1 src.size() src[i 1] *) { i 2; while (i 1 src.size() !(src[i] * src[i 1] /)) { if (src[i] \n) line; i; } i 2; continue; } // 标识符和关键字 if (isalpha(c) || c _) { size_t start i; while (i src.size() (isalnum(src[i]) || src[i] _)) i; std::string word src.substr(start, i - start); auto it keywordMap.find(word); tokens.push_back({it ! keywordMap.end() ? it-second : TokenType::IDENT, word, 0.0, line}); continue; } // 数字整数和浮点带存储过程 if (isdigit(c)) { size_t start i; bool isFloat false; while (i src.size() (isdigit(src[i]) || src[i] .)) { if (src[i] .) { if (isFloat) break; // 第二个小数点截断 isFloat true; } i; } std::string numstr src.substr(start, i - start); tokens.push_back({isFloat ? TokenType::FLOAT_LIT : TokenType::INT_LIT, numstr, std::stod(numstr), line}); continue; } // 运算符先试双字符再试单字符 std::string two src.substr(i, 2); if (two ) { tokens.push_back({TokenType::EQ, two, 0.0, line}); i 2; continue; } if (two !) { tokens.push_back({TokenType::NEQ, two, 0.0, line}); i 2; continue; } if (two ) { tokens.push_back({TokenType::LE, two, 0.0, line}); i 2; continue; } if (two ) { tokens.push_back({TokenType::GE, two, 0.0, line}); i 2; continue; } if (two ) { tokens.push_back({TokenType::AND, two, 0.0, line}); i 2; continue; } if (two ||) { tokens.push_back({TokenType::OR, two, 0.0, line}); i 2; continue; } switch (c) { case : tokens.push_back({TokenType::PLUS, , 0.0, line}); i; break; case -: tokens.push_back({TokenType::MINUS, -, 0.0, line}); i; break; // ... 其余单字符运算符同理 default: throw std::runtime_error(line std::to_string(line) : 无法识别的字符); } } tokens.push_back({TokenType::END, , 0.0, line}); return tokens; }这段代码需要注意三个点。第一个是数字扫描while (isdigit(src[i]) || src[i] .)是有问题的写法因为像1.2.3会被整个吞进去把两个数字字面量变成一个非法 token。我这里用isFloat判断第二次遇到小数点就 break把少截的交给语法分析阶段报错而不是词法阶段死循环。第二个是两个字符的运算符要优先匹配否则a b会被拆成和。第三个是注释处理必须出现在运算符处理之前否则//会被当成两个除号。2.3 语法分析路线递归下降与 LR 的选型理由类C文法是典型的上下文无关文法语法分析路线有三条手写递归下降、用 yacc/bison 生成 LR、以及把文法改写后用 LL(1) 预测分析。课程设计里九成的人选递归下降因为错误信息是逐句报的调试时能直接看到是在哪个产生式上断的。yacc 生成的是 LALR 表改一个小规则要重新生成整张大表答辩时很难解释“这个冲突为什么这么消解”。递归下降的弱点在表达式和嵌套结构上。表达式文法天然左递归必须改写为右递归再用循环收集运算符。嵌套受限在递归深度块嵌套层级很深时会发生栈溢出这点我放到第 5 章的避坑部分细讲。下面是表达式解析的改写版class Parser { public: // expr : additive_expr std::unique_ptrExpr parseExpr() { return parseOrExpr(); } private: // or_expr : and_expr (|| and_expr)* std::unique_ptrExpr parseOrExpr() { auto left parseAndExpr(); while (peek().type TokenType::OR) { next(); auto right parseAndExpr(); left std::make_uniqueBinaryExpr(TokenType::OR, std::move(left), std::move(right)); } return left; } // and_expr : additive ( additive)* std::unique_ptrExpr parseAndExpr() { auto left parseAdditive(); while (peek().type TokenType::AND) { next(); auto right parseAdditive(); left std::make_uniqueBinaryExpr(TokenType::AND, std::move(left), std::move(right)); } return left; } // additive : mul ((|-) mul)* std::unique_ptrExpr parseAdditive() { auto left parseMul(); while (peek().type TokenType::PLUS || peek().type TokenType::MINUS) { TokenType op peek().type; next(); auto right parseMul(); left std::make_uniqueBinaryExpr(op, std::move(left), std::move(right)); } return left; } };这套写法的关键是“循环吞掉同一层级的运算符”让a b - c天然左结合不需要额外建左结合语法树。原始文法里的左递归产生式additive_expr : additive_expr mul_expr这里消失换成长度有限的 while 循环。初学最常踩的坑是递归下降函数写成了无限递归parseAdditive里第一步就调parseAdditive栈爆。这个我在避坑章节再展开。优先级矩阵记得写到文档里。表达式的层序要从高到低排一元运算!、负号 */-!||。每一层对应一个函数函数名和表格对上答辩时你直接指着表说“我的优先级是用函数调用层次实现的”比解释任何算法都快。2.4 AST 节点设计产生式到语法树的映射约定语法分析产物不是三地址码而是一棵可以反复遍历的语法树AST。课程设计常见的偷懒做法是在 parser 里边识别边生成中间代码省掉 AST。这个做法前期快后期加类型检查时必然抓瞎因为类型检查要在所有声明都进符号表之后做顺序和 parse 顺序不一定一致。AST 节点我推荐用继承加 unique_ptr 的组合每个产生式映射一个节点类。好处是遍历时代码整洁坏处是节点类数量多一些。类C子集也就 20 个左右的节点类完全可控。核心结构如下struct Expr { virtual ~Expr() default; virtual void dump(int indent) 0; // 可视化用 }; struct BinaryExpr : Expr { TokenType op; std::unique_ptrExpr left; std::unique_ptrExpr right; BinaryExpr(TokenType op_, std::unique_ptrExpr l, std::unique_ptrExpr r) : op(op_), left(std::move(l)), right(std::move(r)) {} }; struct IntLitExpr : Expr { int value; explicit IntLitExpr(int v) : value(v) {} }; struct VarRefExpr : Expr { std::string name; Symbol* sym nullptr; // 符号表链接语义分析阶段填入 }; struct AssignStmt { std::unique_ptrExpr target; std::unique_ptrExpr value; }; struct IfStmt { std::unique_ptrExpr cond; std::unique_ptrStmt thenStmt; std::unique_ptrStmt elseStmt; // 可空 };映射约定建议写成三条规则放进文档的“设计说明”部分声明类用结构体表达式类用继承语句类用结构体加枚举标签statement kind。这样做没有虚函数也能区分语句类型对后续遍历友好。AST 转储函数dump现在就写后面排错全靠它别等出 bug 了再补。3. 符号表与语义分析落地作用域栈、类型检查与三地址码3.1 符号表实现链式作用域栈与条目结构词法和语法跑通后编译器才真正进入“课本内容”的部分。符号表有两个经典实现哈希表加作用域链或者树形结构。课程设计用哈希表加作用域栈就够了因为类C子集的作用域只有全局、函数、复合语句三层深度不会超过十几层。我用的方案是std::vector模拟作用域栈每层放一个std::unordered_mapclass SymbolTable { std::vectorstd::unordered_mapstd::string, Symbol scopes; public: void pushScope() { scopes.emplace_back(); } void popScope() { scopes.pop_back(); } // 在当前作用域声明重名返回 false bool declare(const Symbol s) { auto cur scopes.back(); if (cur.count(s.name)) return false; cur[s.name] s; return true; } // 由内向外查找找到最近的一层 Symbol* lookup(const std::string name) { for (int i (int)scopes.size() - 1; i 0; --i) { auto it scopes[i].find(name); if (it ! scopes[i].end()) return it-second; } return nullptr; } };Symbol 结构体里存什么直接决定后面的代码生成好不好写。我的版本是struct Symbol { std::string name; Type type; // 枚举TYPE_INT, TYPE_FLOAT, TYPE_VOID int scopeLevel; // 位于第几层作用域调试用 int offset; // 运行时栈帧中的偏移代码生成阶段填 };这里有个细节lookup返回的是unordered_map里的 value 指针后续代码生成阶段会修改offset字段所以一定要返回非 const 指针。另外declare只查当前作用域这层是有意的C 语言允许内层作用域遮蔽外层同名变量所以声明重名只和本层冲突才算错误。遮蔽逻辑不用另写lookup从内向外找天然实现了遮蔽。3.2 语义检查的时机单遍编译的边界与两遍遍历的取舍语义分析最常见的两种做法。第一种是单遍边 parse 边维护符号表声明完一个变量立刻把它塞进当前作用域后面引用时查不到就报错。这种方法代码量最少函数体内变量声明位置就必须在使用之前和 C 标准要求的“先声明后使用”一致。第二种是两遍先全量 parse 建 AST再单独走一遍语义分析遍历。两遍更接近真实编译器但要额外设计遍历器课设时间紧时不推荐。单遍方案有个必须注意的时序点函数声明要拆成两步。第一步先声明函数签名函数名、返回类型、参数表并压入符号表第二步再进函数体。不然递归调用自己时lookup找不到当前正在定义的函数名会报“未定义函数”。代码如下// 在 decl 解析处 Type retType expectType(); std::string fnName expect(TokenType::IDENT).lexeme; expect(TokenType::LPAREN); // 先注册函数签名参数进符号表 Symbol fnSym{fnName, retType, curLevel, 0}; if (!symbols.declare(fnSym)) { error(函数 fnName 重复定义); } symbols.pushScope(); // 函数体作用域 std::vectorSymbol params parseParams(/* 注册参数 */); for (auto p : params) symbols.declare(p); expect(TokenType::RPAREN); parseCompoundStmt(); // 函数体 symbols.popScope(); // 离开函数体检查return语句的类型和函数返回类型是否匹配放在parseCompoundStmt返回后的位置。具体做法是给每个函数的解析函数传入一个Type expectedReturnType遇到return expr;时当场比对类型。类型不匹配报错但注意void函数里允许裸return;这个分支要单独放行。还有一个课设容易忽略的点表达式里的隐式类型转换。int float在类C子集里应该把 int 提升为 float 再运算中间代码生成时需要插入一个CAST指令。判断时机就在构造BinaryExpr时对比左右子树的类型结果类型取两者中的高优先级类型。3.3 中间代码生成三地址码的教学版指令集三地址码是课程设计里性价比最高的一环它把语法树从“嵌套结构”变成“线性指令流”后面虚拟机直接照着执行。指令集我控制在 16 条以内太多背不住太少像赋值、比较这些场景不好表达。这里给出课设版指令表指令操作数语义ASSIGNa, bb aADDa, b, cc a bSUBa, b, cc a - bMULa, b, cc a * bDIVa, b, cc a / bCASTa, bb 转成 a 的类型CMP_LTa, b, cc (a b)JMPlabel无条件跳转JZlabel, a若 a 0 跳转CALLf, ret调用 f结果放 retRETa返回 aPARAMa压入函数参数临时变量按编号生成t1,t2,t3。每个表达式节点生成代码后返回一个字符串表示结果落在哪个临时变量或原变量里。注意 CMP 指令的结果是 0 或 1和||可以拆成CMP_EQ加JMP的组合或直接生成短路跳转。下面是一个if语句的中间代码生成void genIf(const IfStmt node) { // 条件表达式生成代码结果放在 condReg std::string condReg genExpr(*node.cond); // 为 then 和 else 分支创建 label 编号 int elseLabel newLabel(); int endLabel newLabel(); // 条件为假跳 else 或结尾 emit(JZ, label_ std::to_string(elseLabel), condReg); // then 分支 genStmt(*node.thenStmt); if (node.elseStmt) { emit(JMP, label_ std::to_string(endLabel), ); } emitLabel(elseLabel); // else 分支 if (node.elseStmt) { genStmt(*node.elseStmt); emitLabel(endLabel); } }背熟指挥体系和临时变量命名规则后后面的 while、for、短路求值都是这套逻辑的组合。判断短路求值是否正确的标准很简单感性地说“a b” 如果 a 为假就不能生成对 b 求值的指令。这个测试你后面写测试用例时必须覆盖。生成指令的代码要跟着 AST 的递归结构走所以要有意识地维护std::vectorInstruction quads这个全局结构。课程设计还有一个比较隐蔽的需求跳转目标在生成当期是不知道的所以要留 label 占位等分支处理完后再回填。回填方法是用patchLabel(quads[pos])或维护一个 label 到指令序号的映射建议你在文档的“设计说明”里把回填过程单独写一节答辩老师对它的兴趣远大于对词法分析的兴趣。4. 目标代码生成与运行时栈式虚拟机与课程设计文档4.1 目标代码选型栈式虚拟机比 x86 汇编更适合课程设计中间代码之后往哪走两条经典路线生成真实汇编拿 MASM 或 GAS 汇编器编译运行或者自写解释器执行三地址码。真实汇编的优点是答辩时很唬人缺点是 x86 汇编语法在不同系统上差异太大局部变量偏移计算和栈帧布局稍微弄错一个字节就全体崩调试成本极高。自写解释执行则稳定可控你只需要把三地址码里那 16 条指令翻译成一套简单函数的组合。实践里栈式虚拟机是最常见的折中线三地址码再加一道翻译转成一套更底层的指令集指令在虚拟机里对操作数栈执行。它比“直接执行三地址码”多了一层但让代码生成更简单——表达式只需要压栈弹栈。下面我给出一个可运行的 C 最小虚拟机核心循环enum class InstrOp { PUSH_INT, PUSH_FLOAT, ADD, SUB, MUL, DIV, JMP, JZ, CALL, RET, PRT, HALT }; struct Instr { InstrOp op; double operand; // PUSH 的立即数或 JMP 的偏移 }; class StackVM { std::vectordouble stack_; size_t pc_ 0; public: void run(const std::vectorInstr code) { while (pc_ code.size()) { const Instr ins code[pc_]; switch (ins.op) { case InstrOp::PUSH_INT: case InstrOp::PUSH_FLOAT: stack_.push_back(ins.operand); break; case InstrOp::ADD: { double b stack_.back(); stack_.pop_back(); double a stack_.back(); stack_.pop_back(); stack_.push_back(a b); } break; // SUB、MUL、DIV 结构相同注意减法和除法的操作数顺序 case InstrOp::JMP: pc_ (size_t)ins.operand; continue; case InstrOp::JZ: { double top stack_.back(); stack_.pop_back(); if (top 0.0) { pc_ (size_t)ins.operand; continue; } } break; case InstrOp::PRT: { double top stack_.back(); stack_.pop_back(); printf(%g\n, top); } break; case InstrOp::HALT: return; } pc_; } } };这段代码有两个值得专门和读者交代的细节。一个是 SUB 和 DIV 的操作数弹出顺序后弹出来的放前面作为被减数、被除数。栈上顺序是“左操作数先压、右操作数后压”弹出来时先拿到的是右操作数。另一个是 JZ 的跳转偏移以“条”为单位而不是以字节为单位这个约定要在文档里写清楚不然看指令流的同学会以为偏移单位是字节。4.2 函数调用与栈帧参数传递、返回地址与局部变量布局函数调用是课设里最容易翻车的部分也是答辩老师最喜欢深挖的部分。类C语言的函数调用约定可以简化为调用前把参数按从左到右的顺序压栈随后压入返回地址也就是调用指令的下一条指令在指令流中的下标然后跳转到函数体对应的指令下标。函数体开始处要预留局部变量空间函数内部按需要继续压栈。简化版栈帧布局可以用一张表描述栈区内地址递增方向内容更高地址第 1 个参数第 2 个参数...低地址返回地址最低地址局部变量区起点用这套约定函数体内访问参数和局部变量本质上都是“从当前栈顶往下数偏移”。局部变量在符号表的offset字段里存的是它们距离局部变量区起点的位置。课程设计不需要像真实汇编那样精确计算 rbp直接在虚拟机上用stack_[stack_.size() - 1 - offset]就能取到。这个办法对课设完全够用但对大数组深递归不够因为栈深会持续消耗内存。CALL 指令的执行流程需要注意返回地址的压入时机。我的常见做法是代码生成阶段在 CALL 指令后紧跟一条 HALT 或一条 JMP 到程序入口之后的指令CALL 执行时把“当前 pc 1”作为返回地址压栈函数执行到 RET 时弹出返回地址跳回调用点之后继续。如果你在虚拟机里看到函数调用后整个程序莫名退出八成是返回地址没压、RET 弹了个操作数当返回地址。4.3 课程设计文档说明设计报告的结构与写作顺序标题里的“文档说明”在交付物里的分量经常被低估。课设答辩的时间一般在十分钟左右老师看代码的时间远远多于听你讲的时间而文档是老师翻的时候快速建立信任的载体。我建议文档按六个部分组织顺序也按这个来写文档章节内容要点写作时机1. 项目概述语言子集能力清单、运行环境、输入输出行为设计之初写选型和测试结果后补2. 文法定义词法符号定义、BNF 文法、优先级表代码动工前写之后基本不改3. 总体架构模块划分图、数据流图源码→token→AST→三地址码→执行架构确定后写4. 模块设计词法/语法/语义/代码生成四个模块的关键数据结构和流程每个模块完成后立刻写别攒到最后5. 测试报告测试用例列表、每个用例的期望输出与实际输出、截图全程同步积累6. 问题与解决你在开发中遇到的最深 3 个坑、现象、定位过程、修复方案答辩前一周集中补文档写作有个血泪经验模块设计部分不要贴大段代码而是画图加伪代码。可以用 draw.io 画 DFA 状态图、AST 结构图和虚拟机运行流程图图比文字容易过目。伪代码控制在每段 20 行内注释写“这个阶段为什么这么做”而不是“代码做了啥”。5. 课设级编译器最常见的 7 个坑现象、原因与排查手法5.1 现象else 永远配对给最近的 if写评测脚本的时候发现if (a) if (b) x 1; else x 2;这段代码当a为 0 时x竟然被赋成了 2。原因是文法里的悬空 elseif_stmt : if ( expr ) stmt | if ( expr ) stmt else stmt没有说明 else 和哪个 if 绑定递归下降解析时 else 被就近匹配给了内层 if。解决方法是文法不变在parseIfStmt里禁止else之前的stmt是“裸 if 语句”的情况只有在内层 if 用复合语句包住时才允许 else 匹配外层。这个坑不需要算法改一句判断条件就能过。5.2 现象变量在声明前使用时不报错符号表查找时机没对齐导致的。有些同学在 scan 阶段就把所有变量名先记录进符号表后续 lookup 永远查得到所以a 1; int a;也会通过编译。解决方法是声明必须发生在 parse 到var_decl产生式时查找发生在 parse 到表达式里的标识符时两者都由 parser 触发。如果你想做两遍扫描就得留一个“未声明变量列表”然后在第二遍补报错课设别这么干。5.3 现象表达式a / b两个整数相除结果带了小数类C子集已经定义了int / int结果应截断为 int但代码生成只生成了一条 DIV 指令虚拟机上直接用a / b做浮点除法。原因是没有做类型推导BinaryExpr里没记录左右操作数的类型。解决方法是语义分析阶段给每个 Expr 节点附加一个Type resultType字段除法运算时若两侧都是 int则生成指令INT_DIV或在虚拟机里用(int)a / (int)b再转回 double。这个坑最大的迷惑点在于大部分测试用例里4/2看不出错误只有5/2才知道错了。5.4 现象退出复合语句块后块内变量还能被外层代码访问符号表实现里popScope()写完但lookup的实现偷懒用了“全表查找”退栈后没真正删除这层映射导致变量残留。解决方法是做一次自查声明代码测试用例用{ int x 1; } x 2;应报“未声明变量”。如果你的lookup是遍历vectorunordered_map并且只返回最后一个匹配那 pop 掉一层后自然查不到——很多同学把作用域栈写成了只进不出的 vector这才是根源。调试时把符号表每层的内容和scopeLevel一起打印出来立刻见分晓。5.5 现象语法错误后程序进入死循环parser 抛异常后的错误恢复逻辑写成了while (peek().type ! TK_EOF) advanceToken();死循环原因是指针 advance 逻辑 bug 导致某个 token 永远不会被消费。最常见的场景是一个;被误读成了其他 token或者 tokenizer 在无法识别的字符处抛了异常但 parser 没有捕获。建议把错误恢复代码统一成同步点synchronization token方案遇到错误后跳过直到遇到;或}在这两个符号处重置 parser 状态。同步点至少要有不要求在错误行上做精确报告。5.6 现象递归下降解析表达式时直接爆栈左递归在文法里必然出现比如expr : expr term。如果按原文法逐字翻译成parseExpr()里第一步就调parseExpr()等于无限递归到栈溢出。解决办法在前面 2.3 节已经给过把expr term改写成parseExpr 先 parse term再循环处理 。判断自己有没有写好用a b c d测试看看 AST 深度是不是常数级。如果解析 10 个加法就崩那多半是没有用 while 循环而是用了嵌套调用。5.7 现象超深嵌套表达式导致 C 递归栈溢出所有 parser 函数都是递归的深层嵌套的括号((((...))))会占满系统栈。课设环境默认栈大小在 8MB 左右每层递归栈帧大约几百字节几十万层的嵌套才会崩。但由于老师会顺手写一个深度嵌套的测试用例来压测所以最好在文档里写明“本编译器最大嵌套深度为 N”并在 parser 入口加一层深度计数器超过 1024 层直接报“表达式嵌套过深”。这个不是缺陷而是所有递归下降实现的共同边界主动声明比被动宕机好得多。6. 用差分测试与 AST 转储验证编译器从跑通到敢交6.1 一个脚本化的差分测试框架课设验收前你需要的不是更多功能而是确信“这些功能不会因为我改了一个小地方而崩掉”。常见做法是写一组测试用例文件每个文件配一个期望输出用一个脚本批量跑。下面是我用的 Python 差分测试脚本编译与运行都假设在命令行完成import subprocess, pathlib, sys cases_dir pathlib.Path(test_cases) / ok # 正确程序 runner build/myc_compiler ok 0 total 0 for c in sorted(cases_dir.glob(*.c)): total 1 # 编译生成指令文件 comp subprocess.run([runner, str(c), -o, out.vm], capture_outputTrue, textTrue) if comp.returncode ! 0: print(fFAIL compile {c.name}: {comp.stderr}) continue # 执行虚拟机 run subprocess.run([./build/vm, out.vm], capture_outputTrue, textTrue) expected (cases_dir / (c.stem .out)).read_text().strip() actual run.stdout.strip() if actual expected: ok 1 else: print(fFAIL run {c.name}: expect {expected!r}, got {actual!r}) print(f{ok}/{total} passed)这套脚本的价值不只是验收而是给你一个安全的修改底线。你在加新功能前跑一遍如果原有的测试挂了立刻知道哪里改坏了不用对着代码瞎猜。注意测试用例里必须包含边界情况5/2的整数截断、if悬空 else 配对、递归调用如阶乘、嵌套块作用域遮蔽。正确程序之外还要建一个bad/目录放“应该报错”的输入检查编译器是否真的报错——这个更能证明语义检查是活的。6.2 用 AST 转储和中间代码转储定位逻辑错误编译器出 bug 时第一件事不是改代码而是确认“编译到哪一步出错的”。AST 转储函数dump在 2.4 节留了接口这里补全实现。我在每个节点类里都实现输出用缩进表示层级// BinaryExpr::dump void dump(int indent) override { std::cout std::string(indent, ) Binary( tokenTypeName(op) )\n; left-dump(indent 2); right-dump(indent 2); }运行输出大致是Binary() IntLit(1) Binary(*) IntLit(2) IntLit(3)把 AST 转储和三地址码转储并列打印对照着看AST 表明解析正确三地址码说明代码生成正确两者不一致时问题就锁定在中间代码生成阶段。这比打日志好使也比 gdb 快因为编译器是个管道你必须在管道里插入“示波器”。平时养成习惯编译器每条代码路径维护一个-dump-ast和-dump-ir的调试开关最终它也会出现在你的--help输出里成为答辩时的加分项。6.3 自举是终点吗类C编译器还能往哪走的经验谈课设做完最大的诱惑是往“自举”方向想——让自己的编译器编译自己。我见过的实际情况是除非你的语言子集大到包含结构体、指针、数组、字符串处理这些能力否则自举基本上是被文档和答辩耗死的。自举的边界在于你的类C编译器必须能表达它自己运行时依赖的所有东西包括内存管理和系统调用这个工程量远大于一个学期的课设。所以别碰自举能把 16 条指令的虚拟机优化到“加减乘除不产生多余临时变量”都比它在答辩时有价值。如果还想加功能优先级建议是for循环容易、一元取负和逻辑非容易、break/continue容易、数组中等牵扯下标越界检查、字符串常量中等牵扯转义和运行时内存布局。做完这些再回头看你最初的子集边界文档你会发现当初划掉的每一项都对应着一个值得讲的设计决策。这些记录下来的边界、坑和取舍最后就是要交的文档说明里最有含金量的部分。我自己的习惯是交课设前留一整天专门跑差分测试把bad/目录里所有用例过一遍确认每条错误信息里都有行号。行号报错的体验很玄学——你的编译器功能再少只要错误信息可读老师就觉得工程素养在线反之功能再多报错全是“Segmentation fault”也会被当作不可用。我自己当年被一个“缺少分号但没给行号”的报错坑过答辩老师顺着报错信息查了半天最后发现是我的 scanner 少维护了一行lineNo。从那以后我写 tokenizer 的第一件事就是同步维护行号希望你这一步别省。希望帮到你。本文还有配套的精品资源点击获取 类C编译器课程设计实战：从词法分析到虚拟机的完整实现
简介编译原理课程设计类C语言编译器完整资料包面向计算机专业学生编写编译器课程项目提供从界面编辑到目标代码生成的整套实现。程序支持代码行号、关键字与变量高亮、注释区分与自动补全并能完成词法、语法、语义分析及中间代码优化输出汇编文件和详细编译日志覆盖词法符号串、LR(1)分析表、语法树、符号表、中间代码优化等关键环节。压缩包共104个文件、约25.63MB内含8个C源文件与7个头文件源码、Qt运行库dll、界面截图png、exe可执行程序、pro工程文件及说明文档目录结构便于按模块研读。已有582人学习下载。借助这些资料读者可对照源码与运行效果逐步理解编译原理各阶段的实现细节也可将图形编辑器、分析算法与界面交互方式迁移到自己的课程设计项目中。1. 类C编译器课程设计把形式语言从纸上变成能跑的程序课程设计拿到“类C语言编译器”这个题最迷惑人的地方在于老师要的不是你发明一门新语言而是你把《编译原理》教材里的词法分析、语法分析、语义分析、中间代码生成这几章从纸上的状态转移图和产生式变成一份能打开就跑的源代码和一套能对得上号的文档说明。真正折磨人的是“边界”问题——整数和浮点要不要都支持、数组要不要带下标、函数返回值要不要做类型检查……边界划多了做不完划少了答辩时一句“你这个 if 和 while 嵌套怎么一跑就崩”就把你问住。我按课程设计的常见配置做过类似方案这篇把设计路线、核心代码骨架和最常见的翻车点按顺序讲清楚适合正在赶课设的学生以及想快速拿下一套可用原型的初级开发者。读者最好有 C 基础和一点数据结构知识没有也不影响跟着抄就行。2. 类C语言子集与文法设计先定边界再写 parser2.1 语言子集的取舍类型、语句与控制流的最小可用集动手写代码前第一件事是把“类C”这三个字翻译成一张能力清单。我知道很多同学第一步就去写词法分析结果 token 都切完了才发现文法里没有 for 循环或者函数参数列表没法表达整个设计推倒重来。常见做法是先明确子集范围再写文法最后才碰代码。我一般会这样划边界既能覆盖编译原理的主要考点又能在两周内做完类型int、float加一个 void 用于函数返回值。char 看起来简单实际牵扯到字符串常量和转义字符课设优先级低。语句变量声明、赋值、表达式语句、if-else、while、return。for 可以在有富余时间时加不加不扣分因为 for 可以等价改写为 while。表达式四则运算、比较运算、逻辑运算、||、!支持小括号改变优先级。数组和指针这类复杂类型放到扩展项。函数支持参数列表、递归调用、返回值。不支持函数重载和默认参数。全局变量支持全局声明但不支持跨文件编译所有代码放一个源文件。按这个清单文法可以写成下面这份 baseline后面 parser 和 AST 全都围绕它展开program : decl_list decl_list : decl decl_list | ε decl : type ID ( params ) compound_stmt type : int | float | void params : param_list | ε param_list : param , param_list | param param : type ID compound_stmt : { var_decl_list stmt_list } var_decl_list : var_decl var_decl_list | ε var_decl : type ID ; stmt_list : stmt stmt_list | ε stmt : var_decl | expr_stmt | if_stmt | while_stmt | return_stmt | compound_stmt expr_stmt : expr ; if_stmt : if ( expr ) stmt | if ( expr ) stmt else stmt while_stmt : while ( expr ) stmt return_stmt : return expr ; | return ; expr : additive_expr | expr || additive_expr additive_expr : mul_expr | additive_expr mul_expr | additive_expr - mul_expr mul_expr : unary_expr | mul_expr * unary_expr | mul_expr / unary_expr这份文法里我故意埋了一个坑表达式那几条是左递归的后面写递归下降时要去掉。你现在只需要做的就是把这份文法放进课设文档的“语言定义”章节作为需求基线。文档里建议再画一张表列出“本子集支持 / 扩展项 / 明确不支持”答辩老师一眼就能看出你是思考过边界的而不是胡写一通。2.2 词法分析手写 tokenizer 的关键分支与数字解析陷阱子集定了词法分析就能写了。常见做法有两种用 flex 生成或者手写。课程设计我强烈建议手写因为 flex 生成的是黑匣子答辩被问“你这个状态转移图怎么对应到代码”时很难答。手写一个 tokenizer 也就 200 行左右而且是纯粹的机械活。先定义 token 类型enum class TokenType { IDENT, // 标识符 INT_LIT, // 整型字面量int FLOAT_LIT, // 浮点字面量 KW_INT, KW_FLOAT, KW_VOID, KW_IF, KW_ELSE, KW_WHILE, KW_RETURN, PLUS, MINUS, STAR, SLASH, ASSIGN, EQ, NEQ, LT, GT, LE, GE, AND, OR, NOT, LPAREN, RPAREN, LBRACE, RBRACE, SEMI, COMMA, END }; struct Token { TokenType type; std::string lexeme; double numVal; // 字面量的数值统一用 double 存 int lineNo; // 报错定位用 };然后实现核心的扫描函数std::vectorToken tokenize(const std::string src) { std::vectorToken tokens; size_t i 0, line 1; while (i src.size()) { char c src[i]; // 空白与换行 if (isspace(c)) { if (c \n) line; i; continue; } // 注释// 到行尾或 /* ... */ if (c / i 1 src.size() src[i 1] /) { while (i src.size() src[i] ! \n) i; continue; } if (c / i 1 src.size() src[i 1] *) { i 2; while (i 1 src.size() !(src[i] * src[i 1] /)) { if (src[i] \n) line; i; } i 2; continue; } // 标识符和关键字 if (isalpha(c) || c _) { size_t start i; while (i src.size() (isalnum(src[i]) || src[i] _)) i; std::string word src.substr(start, i - start); auto it keywordMap.find(word); tokens.push_back({it ! keywordMap.end() ? it-second : TokenType::IDENT, word, 0.0, line}); continue; } // 数字整数和浮点带存储过程 if (isdigit(c)) { size_t start i; bool isFloat false; while (i src.size() (isdigit(src[i]) || src[i] .)) { if (src[i] .) { if (isFloat) break; // 第二个小数点截断 isFloat true; } i; } std::string numstr src.substr(start, i - start); tokens.push_back({isFloat ? TokenType::FLOAT_LIT : TokenType::INT_LIT, numstr, std::stod(numstr), line}); continue; } // 运算符先试双字符再试单字符 std::string two src.substr(i, 2); if (two ) { tokens.push_back({TokenType::EQ, two, 0.0, line}); i 2; continue; } if (two !) { tokens.push_back({TokenType::NEQ, two, 0.0, line}); i 2; continue; } if (two ) { tokens.push_back({TokenType::LE, two, 0.0, line}); i 2; continue; } if (two ) { tokens.push_back({TokenType::GE, two, 0.0, line}); i 2; continue; } if (two ) { tokens.push_back({TokenType::AND, two, 0.0, line}); i 2; continue; } if (two ||) { tokens.push_back({TokenType::OR, two, 0.0, line}); i 2; continue; } switch (c) { case : tokens.push_back({TokenType::PLUS, , 0.0, line}); i; break; case -: tokens.push_back({TokenType::MINUS, -, 0.0, line}); i; break; // ... 其余单字符运算符同理 default: throw std::runtime_error(line std::to_string(line) : 无法识别的字符); } } tokens.push_back({TokenType::END, , 0.0, line}); return tokens; }这段代码需要注意三个点。第一个是数字扫描while (isdigit(src[i]) || src[i] .)是有问题的写法因为像1.2.3会被整个吞进去把两个数字字面量变成一个非法 token。我这里用isFloat判断第二次遇到小数点就 break把少截的交给语法分析阶段报错而不是词法阶段死循环。第二个是两个字符的运算符要优先匹配否则a b会被拆成和。第三个是注释处理必须出现在运算符处理之前否则//会被当成两个除号。2.3 语法分析路线递归下降与 LR 的选型理由类C文法是典型的上下文无关文法语法分析路线有三条手写递归下降、用 yacc/bison 生成 LR、以及把文法改写后用 LL(1) 预测分析。课程设计里九成的人选递归下降因为错误信息是逐句报的调试时能直接看到是在哪个产生式上断的。yacc 生成的是 LALR 表改一个小规则要重新生成整张大表答辩时很难解释“这个冲突为什么这么消解”。递归下降的弱点在表达式和嵌套结构上。表达式文法天然左递归必须改写为右递归再用循环收集运算符。嵌套受限在递归深度块嵌套层级很深时会发生栈溢出这点我放到第 5 章的避坑部分细讲。下面是表达式解析的改写版class Parser { public: // expr : additive_expr std::unique_ptrExpr parseExpr() { return parseOrExpr(); } private: // or_expr : and_expr (|| and_expr)* std::unique_ptrExpr parseOrExpr() { auto left parseAndExpr(); while (peek().type TokenType::OR) { next(); auto right parseAndExpr(); left std::make_uniqueBinaryExpr(TokenType::OR, std::move(left), std::move(right)); } return left; } // and_expr : additive ( additive)* std::unique_ptrExpr parseAndExpr() { auto left parseAdditive(); while (peek().type TokenType::AND) { next(); auto right parseAdditive(); left std::make_uniqueBinaryExpr(TokenType::AND, std::move(left), std::move(right)); } return left; } // additive : mul ((|-) mul)* std::unique_ptrExpr parseAdditive() { auto left parseMul(); while (peek().type TokenType::PLUS || peek().type TokenType::MINUS) { TokenType op peek().type; next(); auto right parseMul(); left std::make_uniqueBinaryExpr(op, std::move(left), std::move(right)); } return left; } };这套写法的关键是“循环吞掉同一层级的运算符”让a b - c天然左结合不需要额外建左结合语法树。原始文法里的左递归产生式additive_expr : additive_expr mul_expr这里消失换成长度有限的 while 循环。初学最常踩的坑是递归下降函数写成了无限递归parseAdditive里第一步就调parseAdditive栈爆。这个我在避坑章节再展开。优先级矩阵记得写到文档里。表达式的层序要从高到低排一元运算!、负号 */-!||。每一层对应一个函数函数名和表格对上答辩时你直接指着表说“我的优先级是用函数调用层次实现的”比解释任何算法都快。2.4 AST 节点设计产生式到语法树的映射约定语法分析产物不是三地址码而是一棵可以反复遍历的语法树AST。课程设计常见的偷懒做法是在 parser 里边识别边生成中间代码省掉 AST。这个做法前期快后期加类型检查时必然抓瞎因为类型检查要在所有声明都进符号表之后做顺序和 parse 顺序不一定一致。AST 节点我推荐用继承加 unique_ptr 的组合每个产生式映射一个节点类。好处是遍历时代码整洁坏处是节点类数量多一些。类C子集也就 20 个左右的节点类完全可控。核心结构如下struct Expr { virtual ~Expr() default; virtual void dump(int indent) 0; // 可视化用 }; struct BinaryExpr : Expr { TokenType op; std::unique_ptrExpr left; std::unique_ptrExpr right; BinaryExpr(TokenType op_, std::unique_ptrExpr l, std::unique_ptrExpr r) : op(op_), left(std::move(l)), right(std::move(r)) {} }; struct IntLitExpr : Expr { int value; explicit IntLitExpr(int v) : value(v) {} }; struct VarRefExpr : Expr { std::string name; Symbol* sym nullptr; // 符号表链接语义分析阶段填入 }; struct AssignStmt { std::unique_ptrExpr target; std::unique_ptrExpr value; }; struct IfStmt { std::unique_ptrExpr cond; std::unique_ptrStmt thenStmt; std::unique_ptrStmt elseStmt; // 可空 };映射约定建议写成三条规则放进文档的“设计说明”部分声明类用结构体表达式类用继承语句类用结构体加枚举标签statement kind。这样做没有虚函数也能区分语句类型对后续遍历友好。AST 转储函数dump现在就写后面排错全靠它别等出 bug 了再补。3. 符号表与语义分析落地作用域栈、类型检查与三地址码3.1 符号表实现链式作用域栈与条目结构词法和语法跑通后编译器才真正进入“课本内容”的部分。符号表有两个经典实现哈希表加作用域链或者树形结构。课程设计用哈希表加作用域栈就够了因为类C子集的作用域只有全局、函数、复合语句三层深度不会超过十几层。我用的方案是std::vector模拟作用域栈每层放一个std::unordered_mapclass SymbolTable { std::vectorstd::unordered_mapstd::string, Symbol scopes; public: void pushScope() { scopes.emplace_back(); } void popScope() { scopes.pop_back(); } // 在当前作用域声明重名返回 false bool declare(const Symbol s) { auto cur scopes.back(); if (cur.count(s.name)) return false; cur[s.name] s; return true; } // 由内向外查找找到最近的一层 Symbol* lookup(const std::string name) { for (int i (int)scopes.size() - 1; i 0; --i) { auto it scopes[i].find(name); if (it ! scopes[i].end()) return it-second; } return nullptr; } };Symbol 结构体里存什么直接决定后面的代码生成好不好写。我的版本是struct Symbol { std::string name; Type type; // 枚举TYPE_INT, TYPE_FLOAT, TYPE_VOID int scopeLevel; // 位于第几层作用域调试用 int offset; // 运行时栈帧中的偏移代码生成阶段填 };这里有个细节lookup返回的是unordered_map里的 value 指针后续代码生成阶段会修改offset字段所以一定要返回非 const 指针。另外declare只查当前作用域这层是有意的C 语言允许内层作用域遮蔽外层同名变量所以声明重名只和本层冲突才算错误。遮蔽逻辑不用另写lookup从内向外找天然实现了遮蔽。3.2 语义检查的时机单遍编译的边界与两遍遍历的取舍语义分析最常见的两种做法。第一种是单遍边 parse 边维护符号表声明完一个变量立刻把它塞进当前作用域后面引用时查不到就报错。这种方法代码量最少函数体内变量声明位置就必须在使用之前和 C 标准要求的“先声明后使用”一致。第二种是两遍先全量 parse 建 AST再单独走一遍语义分析遍历。两遍更接近真实编译器但要额外设计遍历器课设时间紧时不推荐。单遍方案有个必须注意的时序点函数声明要拆成两步。第一步先声明函数签名函数名、返回类型、参数表并压入符号表第二步再进函数体。不然递归调用自己时lookup找不到当前正在定义的函数名会报“未定义函数”。代码如下// 在 decl 解析处 Type retType expectType(); std::string fnName expect(TokenType::IDENT).lexeme; expect(TokenType::LPAREN); // 先注册函数签名参数进符号表 Symbol fnSym{fnName, retType, curLevel, 0}; if (!symbols.declare(fnSym)) { error(函数 fnName 重复定义); } symbols.pushScope(); // 函数体作用域 std::vectorSymbol params parseParams(/* 注册参数 */); for (auto p : params) symbols.declare(p); expect(TokenType::RPAREN); parseCompoundStmt(); // 函数体 symbols.popScope(); // 离开函数体检查return语句的类型和函数返回类型是否匹配放在parseCompoundStmt返回后的位置。具体做法是给每个函数的解析函数传入一个Type expectedReturnType遇到return expr;时当场比对类型。类型不匹配报错但注意void函数里允许裸return;这个分支要单独放行。还有一个课设容易忽略的点表达式里的隐式类型转换。int float在类C子集里应该把 int 提升为 float 再运算中间代码生成时需要插入一个CAST指令。判断时机就在构造BinaryExpr时对比左右子树的类型结果类型取两者中的高优先级类型。3.3 中间代码生成三地址码的教学版指令集三地址码是课程设计里性价比最高的一环它把语法树从“嵌套结构”变成“线性指令流”后面虚拟机直接照着执行。指令集我控制在 16 条以内太多背不住太少像赋值、比较这些场景不好表达。这里给出课设版指令表指令操作数语义ASSIGNa, bb aADDa, b, cc a bSUBa, b, cc a - bMULa, b, cc a * bDIVa, b, cc a / bCASTa, bb 转成 a 的类型CMP_LTa, b, cc (a b)JMPlabel无条件跳转JZlabel, a若 a 0 跳转CALLf, ret调用 f结果放 retRETa返回 aPARAMa压入函数参数临时变量按编号生成t1,t2,t3。每个表达式节点生成代码后返回一个字符串表示结果落在哪个临时变量或原变量里。注意 CMP 指令的结果是 0 或 1和||可以拆成CMP_EQ加JMP的组合或直接生成短路跳转。下面是一个if语句的中间代码生成void genIf(const IfStmt node) { // 条件表达式生成代码结果放在 condReg std::string condReg genExpr(*node.cond); // 为 then 和 else 分支创建 label 编号 int elseLabel newLabel(); int endLabel newLabel(); // 条件为假跳 else 或结尾 emit(JZ, label_ std::to_string(elseLabel), condReg); // then 分支 genStmt(*node.thenStmt); if (node.elseStmt) { emit(JMP, label_ std::to_string(endLabel), ); } emitLabel(elseLabel); // else 分支 if (node.elseStmt) { genStmt(*node.elseStmt); emitLabel(endLabel); } }背熟指挥体系和临时变量命名规则后后面的 while、for、短路求值都是这套逻辑的组合。判断短路求值是否正确的标准很简单感性地说“a b” 如果 a 为假就不能生成对 b 求值的指令。这个测试你后面写测试用例时必须覆盖。生成指令的代码要跟着 AST 的递归结构走所以要有意识地维护std::vectorInstruction quads这个全局结构。课程设计还有一个比较隐蔽的需求跳转目标在生成当期是不知道的所以要留 label 占位等分支处理完后再回填。回填方法是用patchLabel(quads[pos])或维护一个 label 到指令序号的映射建议你在文档的“设计说明”里把回填过程单独写一节答辩老师对它的兴趣远大于对词法分析的兴趣。4. 目标代码生成与运行时栈式虚拟机与课程设计文档4.1 目标代码选型栈式虚拟机比 x86 汇编更适合课程设计中间代码之后往哪走两条经典路线生成真实汇编拿 MASM 或 GAS 汇编器编译运行或者自写解释器执行三地址码。真实汇编的优点是答辩时很唬人缺点是 x86 汇编语法在不同系统上差异太大局部变量偏移计算和栈帧布局稍微弄错一个字节就全体崩调试成本极高。自写解释执行则稳定可控你只需要把三地址码里那 16 条指令翻译成一套简单函数的组合。实践里栈式虚拟机是最常见的折中线三地址码再加一道翻译转成一套更底层的指令集指令在虚拟机里对操作数栈执行。它比“直接执行三地址码”多了一层但让代码生成更简单——表达式只需要压栈弹栈。下面我给出一个可运行的 C 最小虚拟机核心循环enum class InstrOp { PUSH_INT, PUSH_FLOAT, ADD, SUB, MUL, DIV, JMP, JZ, CALL, RET, PRT, HALT }; struct Instr { InstrOp op; double operand; // PUSH 的立即数或 JMP 的偏移 }; class StackVM { std::vectordouble stack_; size_t pc_ 0; public: void run(const std::vectorInstr code) { while (pc_ code.size()) { const Instr ins code[pc_]; switch (ins.op) { case InstrOp::PUSH_INT: case InstrOp::PUSH_FLOAT: stack_.push_back(ins.operand); break; case InstrOp::ADD: { double b stack_.back(); stack_.pop_back(); double a stack_.back(); stack_.pop_back(); stack_.push_back(a b); } break; // SUB、MUL、DIV 结构相同注意减法和除法的操作数顺序 case InstrOp::JMP: pc_ (size_t)ins.operand; continue; case InstrOp::JZ: { double top stack_.back(); stack_.pop_back(); if (top 0.0) { pc_ (size_t)ins.operand; continue; } } break; case InstrOp::PRT: { double top stack_.back(); stack_.pop_back(); printf(%g\n, top); } break; case InstrOp::HALT: return; } pc_; } } };这段代码有两个值得专门和读者交代的细节。一个是 SUB 和 DIV 的操作数弹出顺序后弹出来的放前面作为被减数、被除数。栈上顺序是“左操作数先压、右操作数后压”弹出来时先拿到的是右操作数。另一个是 JZ 的跳转偏移以“条”为单位而不是以字节为单位这个约定要在文档里写清楚不然看指令流的同学会以为偏移单位是字节。4.2 函数调用与栈帧参数传递、返回地址与局部变量布局函数调用是课设里最容易翻车的部分也是答辩老师最喜欢深挖的部分。类C语言的函数调用约定可以简化为调用前把参数按从左到右的顺序压栈随后压入返回地址也就是调用指令的下一条指令在指令流中的下标然后跳转到函数体对应的指令下标。函数体开始处要预留局部变量空间函数内部按需要继续压栈。简化版栈帧布局可以用一张表描述栈区内地址递增方向内容更高地址第 1 个参数第 2 个参数...低地址返回地址最低地址局部变量区起点用这套约定函数体内访问参数和局部变量本质上都是“从当前栈顶往下数偏移”。局部变量在符号表的offset字段里存的是它们距离局部变量区起点的位置。课程设计不需要像真实汇编那样精确计算 rbp直接在虚拟机上用stack_[stack_.size() - 1 - offset]就能取到。这个办法对课设完全够用但对大数组深递归不够因为栈深会持续消耗内存。CALL 指令的执行流程需要注意返回地址的压入时机。我的常见做法是代码生成阶段在 CALL 指令后紧跟一条 HALT 或一条 JMP 到程序入口之后的指令CALL 执行时把“当前 pc 1”作为返回地址压栈函数执行到 RET 时弹出返回地址跳回调用点之后继续。如果你在虚拟机里看到函数调用后整个程序莫名退出八成是返回地址没压、RET 弹了个操作数当返回地址。4.3 课程设计文档说明设计报告的结构与写作顺序标题里的“文档说明”在交付物里的分量经常被低估。课设答辩的时间一般在十分钟左右老师看代码的时间远远多于听你讲的时间而文档是老师翻的时候快速建立信任的载体。我建议文档按六个部分组织顺序也按这个来写文档章节内容要点写作时机1. 项目概述语言子集能力清单、运行环境、输入输出行为设计之初写选型和测试结果后补2. 文法定义词法符号定义、BNF 文法、优先级表代码动工前写之后基本不改3. 总体架构模块划分图、数据流图源码→token→AST→三地址码→执行架构确定后写4. 模块设计词法/语法/语义/代码生成四个模块的关键数据结构和流程每个模块完成后立刻写别攒到最后5. 测试报告测试用例列表、每个用例的期望输出与实际输出、截图全程同步积累6. 问题与解决你在开发中遇到的最深 3 个坑、现象、定位过程、修复方案答辩前一周集中补文档写作有个血泪经验模块设计部分不要贴大段代码而是画图加伪代码。可以用 draw.io 画 DFA 状态图、AST 结构图和虚拟机运行流程图图比文字容易过目。伪代码控制在每段 20 行内注释写“这个阶段为什么这么做”而不是“代码做了啥”。5. 课设级编译器最常见的 7 个坑现象、原因与排查手法5.1 现象else 永远配对给最近的 if写评测脚本的时候发现if (a) if (b) x 1; else x 2;这段代码当a为 0 时x竟然被赋成了 2。原因是文法里的悬空 elseif_stmt : if ( expr ) stmt | if ( expr ) stmt else stmt没有说明 else 和哪个 if 绑定递归下降解析时 else 被就近匹配给了内层 if。解决方法是文法不变在parseIfStmt里禁止else之前的stmt是“裸 if 语句”的情况只有在内层 if 用复合语句包住时才允许 else 匹配外层。这个坑不需要算法改一句判断条件就能过。5.2 现象变量在声明前使用时不报错符号表查找时机没对齐导致的。有些同学在 scan 阶段就把所有变量名先记录进符号表后续 lookup 永远查得到所以a 1; int a;也会通过编译。解决方法是声明必须发生在 parse 到var_decl产生式时查找发生在 parse 到表达式里的标识符时两者都由 parser 触发。如果你想做两遍扫描就得留一个“未声明变量列表”然后在第二遍补报错课设别这么干。5.3 现象表达式a / b两个整数相除结果带了小数类C子集已经定义了int / int结果应截断为 int但代码生成只生成了一条 DIV 指令虚拟机上直接用a / b做浮点除法。原因是没有做类型推导BinaryExpr里没记录左右操作数的类型。解决方法是语义分析阶段给每个 Expr 节点附加一个Type resultType字段除法运算时若两侧都是 int则生成指令INT_DIV或在虚拟机里用(int)a / (int)b再转回 double。这个坑最大的迷惑点在于大部分测试用例里4/2看不出错误只有5/2才知道错了。5.4 现象退出复合语句块后块内变量还能被外层代码访问符号表实现里popScope()写完但lookup的实现偷懒用了“全表查找”退栈后没真正删除这层映射导致变量残留。解决方法是做一次自查声明代码测试用例用{ int x 1; } x 2;应报“未声明变量”。如果你的lookup是遍历vectorunordered_map并且只返回最后一个匹配那 pop 掉一层后自然查不到——很多同学把作用域栈写成了只进不出的 vector这才是根源。调试时把符号表每层的内容和scopeLevel一起打印出来立刻见分晓。5.5 现象语法错误后程序进入死循环parser 抛异常后的错误恢复逻辑写成了while (peek().type ! TK_EOF) advanceToken();死循环原因是指针 advance 逻辑 bug 导致某个 token 永远不会被消费。最常见的场景是一个;被误读成了其他 token或者 tokenizer 在无法识别的字符处抛了异常但 parser 没有捕获。建议把错误恢复代码统一成同步点synchronization token方案遇到错误后跳过直到遇到;或}在这两个符号处重置 parser 状态。同步点至少要有不要求在错误行上做精确报告。5.6 现象递归下降解析表达式时直接爆栈左递归在文法里必然出现比如expr : expr term。如果按原文法逐字翻译成parseExpr()里第一步就调parseExpr()等于无限递归到栈溢出。解决办法在前面 2.3 节已经给过把expr term改写成parseExpr 先 parse term再循环处理 。判断自己有没有写好用a b c d测试看看 AST 深度是不是常数级。如果解析 10 个加法就崩那多半是没有用 while 循环而是用了嵌套调用。5.7 现象超深嵌套表达式导致 C 递归栈溢出所有 parser 函数都是递归的深层嵌套的括号((((...))))会占满系统栈。课设环境默认栈大小在 8MB 左右每层递归栈帧大约几百字节几十万层的嵌套才会崩。但由于老师会顺手写一个深度嵌套的测试用例来压测所以最好在文档里写明“本编译器最大嵌套深度为 N”并在 parser 入口加一层深度计数器超过 1024 层直接报“表达式嵌套过深”。这个不是缺陷而是所有递归下降实现的共同边界主动声明比被动宕机好得多。6. 用差分测试与 AST 转储验证编译器从跑通到敢交6.1 一个脚本化的差分测试框架课设验收前你需要的不是更多功能而是确信“这些功能不会因为我改了一个小地方而崩掉”。常见做法是写一组测试用例文件每个文件配一个期望输出用一个脚本批量跑。下面是我用的 Python 差分测试脚本编译与运行都假设在命令行完成import subprocess, pathlib, sys cases_dir pathlib.Path(test_cases) / ok # 正确程序 runner build/myc_compiler ok 0 total 0 for c in sorted(cases_dir.glob(*.c)): total 1 # 编译生成指令文件 comp subprocess.run([runner, str(c), -o, out.vm], capture_outputTrue, textTrue) if comp.returncode ! 0: print(fFAIL compile {c.name}: {comp.stderr}) continue # 执行虚拟机 run subprocess.run([./build/vm, out.vm], capture_outputTrue, textTrue) expected (cases_dir / (c.stem .out)).read_text().strip() actual run.stdout.strip() if actual expected: ok 1 else: print(fFAIL run {c.name}: expect {expected!r}, got {actual!r}) print(f{ok}/{total} passed)这套脚本的价值不只是验收而是给你一个安全的修改底线。你在加新功能前跑一遍如果原有的测试挂了立刻知道哪里改坏了不用对着代码瞎猜。注意测试用例里必须包含边界情况5/2的整数截断、if悬空 else 配对、递归调用如阶乘、嵌套块作用域遮蔽。正确程序之外还要建一个bad/目录放“应该报错”的输入检查编译器是否真的报错——这个更能证明语义检查是活的。6.2 用 AST 转储和中间代码转储定位逻辑错误编译器出 bug 时第一件事不是改代码而是确认“编译到哪一步出错的”。AST 转储函数dump在 2.4 节留了接口这里补全实现。我在每个节点类里都实现输出用缩进表示层级// BinaryExpr::dump void dump(int indent) override { std::cout std::string(indent, ) Binary( tokenTypeName(op) )\n; left-dump(indent 2); right-dump(indent 2); }运行输出大致是Binary() IntLit(1) Binary(*) IntLit(2) IntLit(3)把 AST 转储和三地址码转储并列打印对照着看AST 表明解析正确三地址码说明代码生成正确两者不一致时问题就锁定在中间代码生成阶段。这比打日志好使也比 gdb 快因为编译器是个管道你必须在管道里插入“示波器”。平时养成习惯编译器每条代码路径维护一个-dump-ast和-dump-ir的调试开关最终它也会出现在你的--help输出里成为答辩时的加分项。6.3 自举是终点吗类C编译器还能往哪走的经验谈课设做完最大的诱惑是往“自举”方向想——让自己的编译器编译自己。我见过的实际情况是除非你的语言子集大到包含结构体、指针、数组、字符串处理这些能力否则自举基本上是被文档和答辩耗死的。自举的边界在于你的类C编译器必须能表达它自己运行时依赖的所有东西包括内存管理和系统调用这个工程量远大于一个学期的课设。所以别碰自举能把 16 条指令的虚拟机优化到“加减乘除不产生多余临时变量”都比它在答辩时有价值。如果还想加功能优先级建议是for循环容易、一元取负和逻辑非容易、break/continue容易、数组中等牵扯下标越界检查、字符串常量中等牵扯转义和运行时内存布局。做完这些再回头看你最初的子集边界文档你会发现当初划掉的每一项都对应着一个值得讲的设计决策。这些记录下来的边界、坑和取舍最后就是要交的文档说明里最有含金量的部分。我自己的习惯是交课设前留一整天专门跑差分测试把bad/目录里所有用例过一遍确认每条错误信息里都有行号。行号报错的体验很玄学——你的编译器功能再少只要错误信息可读老师就觉得工程素养在线反之功能再多报错全是“Segmentation fault”也会被当作不可用。我自己当年被一个“缺少分号但没给行号”的报错坑过答辩老师顺着报错信息查了半天最后发现是我的 scanner 少维护了一行lineNo。从那以后我写 tokenizer 的第一件事就是同步维护行号希望你这一步别省。希望帮到你。本文还有配套的精品资源点击获取