编译原理实验报告：构建可验证的编译器工程实践骨架

简介：本资源是东北大学秦皇岛分校编译原理课程的词法分析实验报告，面向计算机专业本科生及编译技术初学者，聚焦PL/0语言词法分析器的设计与C++实现，解决从理论到代码落地的关键实践问题。压缩包为单个122KB的Word文档（.doc），完整包含实验目的、环境配置（Windows+C++）、核心代码（含isLetter/isDigit等字符判断函数及main主流程）、关键词表定义、错误检测逻辑（如识别'2A'类非法标识符）及详细执行流程说明，结构清晰、注释充分，便于理解词法分析各环节衔接。已有98人学习下载，读者可直接复现运行、对照源码调试、掌握单词分类规则与二元组输出机制，并借鉴其模块化函数设计与文件读取处理方式，为后续语法分析实验打下扎实基础。

1. 编译原理实验报告：不是交作业的文档，而是你亲手造出“语言翻译官”的过程记录

如果你刚上完编译原理课，正对着“词法分析→语法分析→语义分析→中间代码生成→优化→目标代码生成”这条流水线发懵；或者你已写完lex/yacc、手撸过递归下降解析器，却卡在“怎么把实验串成一条可验证、可复现、能讲清每一步决策依据的完整证据链”——那这份《编译原理实验报告》就不是课程结业附件，而是你第一次以工程师身份，把抽象理论落地为可执行、可调试、可解释的系统性工程的“黑匣子拆解日志”。它解决的核心问题是：当语法树长出来、四元式填满、寄存器分配完成，你怎么证明每一步没走偏？适合两类人：一是需要靠报告体现工程能力、为后续系统编程/语言设计打基础的学生；二是想用最小代价复现经典实验、跳过教学框架黑盒、直击核心机制的一线开发者。它不教“什么是FIRST集”，但会告诉你“为什么这个FIRST集算出来后，你的LL(1)分析表第3行第7列必须填error”。

2. 从空目录开始：搭建可验证的实验骨架，拒绝“跑通即结束”

编译原理实验最易翻车的起点，是把所有代码塞进一个main.c里，靠printf硬调。这种结构无法隔离模块、无法单步验证、更无法回溯错误源头。我一般会强制按编译流程分层建目录，每个阶段输出明确中间产物，并自带校验钩子。

2.1 目录结构与文件职责：让每一层都“看得见、摸得着”

compiler-exp/ ├── src/ │ ├── lexer/ # 词法分析器：输入源码，输出token流（含行号、位置） │ │ ├── scanner.l # flex定义（或手写DFA实现） │ │ └── token.h # token类型枚举、token结构体定义 │ ├── parser/ # 语法分析器：输入token流，输出AST或语法树 │ │ ├── parser.y # bison定义（或递归下降/LL(1)手写代码） │ │ └── ast.h # AST节点类型、构造函数、打印函数 │ ├── semantic/ # 语义分析：遍历AST，检查类型、作用域、未声明变量等 │ │ └── checker.c # 符号表管理、类型推导、错误收集 │ ├── irgen/ # 中间代码生成：将AST转为三地址码/四元式 │ │ └── ir.c # 四元式结构体、生成规则、临时变量命名策略 │ └── codegen/ # 目标代码生成（如x86-64汇编）：基于IR+寄存器分配 │ └── gen.c # 寄存器分配算法（图着色/线性扫描）、指令选择 ├── test/ # 测试用例驱动：每个test有源码、期望token流、期望AST、期望IR │ ├── valid/ │ │ ├── hello.c # 正确程序 │ │ └── hello.exp # 期望的token序列（逐行比对） │ └── invalid/ │ └── undecl.c # 含未声明变量的错误程序 ├── build/ # 构建产物：.o、可执行文件、中间文件存放地 ├── scripts/ # 自动化脚本：一键运行全链路、对比输出、生成报告 │ └── run_all.sh └── report/ # 实验报告素材：截图、数据表格、关键代码片段、错误分析

提示：test/valid/hello.exp不是随意写的文本，而是由参考实现（如已知正确的lexer）生成的黄金标准（golden output）。每次修改lexer后，必须重新生成并人工确认其合理性——这是避免“自证循环”的第一道防线。

2.2 最小可验证链路：用5行C代码跑通全流程

我们以最简整数加法int a = 1 + 2;为例，验证骨架是否真正贯通：

// test/valid/add.c int main() { int a = 1 + 2; return a; }

执行以下命令，应得到清晰分阶段输出：

# 1. 词法分析：生成token流（带位置信息） $ ./build/lexer < test/valid/add.c > build/add.tokens $ head -n 10 build/add.tokens KEYWORD:int LINE:1 COL:1 ID:main LINE:1 COL:5 LPAREN LINE:1 COL:9 RPAREN LINE:1 COL:10 LBRACE LINE:1 COL:12 KEYWORD:int LINE:2 COL:5 ID:a LINE:2 COL:9 ASSIGN LINE:2 COL:11 INT:1 LINE:2 COL:13 PLUS LINE:2 COL:15 INT:2 LINE:2 COL:17 SEMI LINE:2 COL:18 RBRACE LINE:3 COL:1 # 2. 语法分析：生成AST（文本化表示，便于肉眼核对） $ ./build/parser < build/add.tokens > build/add.ast $ cat build/add.ast Program └── FunctionDef: main └── Block └── Decl: int a └── BinaryOp: + ├── IntLiteral: 1 └── IntLiteral: 2 # 3. 语义分析：输出符号表快照和错误日志 $ ./build/checker < build/add.ast > build/add.sem.log $ cat build/add.sem.log [INFO] Symbol table after main: {a -> type=int, scope=local} [INFO] No semantic errors found. # 4. 中间代码生成：输出四元式序列（标准格式，可被后续阶段消费） $ ./build/irgen < build/add.ast > build/add.ir $ cat build/add.ir t1 = 1 t2 = 2 t3 = t1 + t2 a = t3

逻辑说明：

• lexer读取源码，按flex规则切分token，必须携带LINE/COL，否则后续报错无法定位；
• parser输入是lexer输出的token流（非原始源码），输出AST结构体，ast.h中需提供print_ast()函数，将树转为缩进文本——这是调试语法树是否正确的唯一可靠方式；
• checker接收AST，构建符号表（哈希表+作用域栈），对每个ID节点查表，未查到则报错并记录位置；
• irgen遍历AST，为每个表达式生成临时变量（t1, t2...），命名规则必须全局唯一且可预测（如按DFS序号），否则后续寄存器分配会混乱。

参数说明：

• 所有可执行文件（lexer,parser等）均从stdin读输入、向stdout写输出，禁用文件路径硬编码——这保证了管道（|）串联的可靠性；
• build/目录为构建产物专属区，禁止源码中出现../build/路径，所有I/O通过重定向完成；
• test/下每个用例必须配.exp文件，run_all.sh脚本会自动调用diff比对实际输出与期望输出，任何一行不匹配即标为FAIL。

3. 词法分析器避坑：正则不是万能的，状态机才是你的后悔药

词法分析看似简单，却是实验中最容易“表面跑通、深层崩坏”的环节。很多同学用flex写出能识别int、+、123的规则，却在处理注释嵌套、字符串转义、浮点数边界时集体翻车。以下是血泪经验总结的5个高频坑：

3.1 现象：注释吞掉不该吞的内容，导致后续token错位

原因：flex默认贪婪匹配，"/*"[^*]*"*"+[^/*][^*]*"*"+"/"这类正则在遇到/* comment */ int x;时可能正确，但遇到/* nested /* comment */ */或/* comment with */ inside */时因回溯失败而截断，导致int被吃进注释里。
解决：放弃复杂正则，改用flex的起始条件（start conditions）构建状态机。定义<COMMENT>状态，在/*进入，*/退出，期间所有字符（包括*和/）均忽略。代码片段如下：

%{ #include "token.h" %} %x COMMENT %% "/*" { BEGIN COMMENT; } <COMMENT>"*/" { BEGIN INITIAL; } <COMMENT>. { /* ignore all chars in comment */ } <COMMENT>\n { /* count line, but don't emit newline token */ } [a-zA-Z_][a-zA-Z0-9_]* { yylval.str = strdup(yytext); return ID; } [0-9]+ { yylval.num = atoi(yytext); return INT; } "+" { return PLUS; } ";" { return SEMI; } \n { lineno++; } [ \t] { /* skip whitespace */ } . { fprintf(stderr, "Lexical error at line %d: unknown char '%s'\n", lineno, yytext); exit(1); } %%

注意：<COMMENT>.规则必须放在<COMMENT>"*/"之后，否则*/会被.先匹配掉——flex规则按顺序匹配，顺序即优先级。

3.2 现象：字符串字面量中的\n被识别为换行符，导致行号错乱

原因：flex默认将\n视为行结束符并自动增lineno，但字符串内\n是合法字符，不应触发行号更新。
解决：在字符串状态中禁用自动换行计数，手动处理。添加<STRING>状态：

\" { BEGIN STRING; } <STRING>\" { BEGIN INITIAL; return STRING_LITERAL; } <STRING>\\n { /* append '\n' to string buffer, do NOT increment lineno */ } <STRING>\n { /* ERROR: unescaped newline in string */ } <STRING>\\[0-7]{1,3} { /* octal escape, convert and append */ } <STRING>. { /* append char, except unescaped quote/backslash */ }

3.3 现象：浮点数字面量123.45e-6被切成123.45和e-6两个token

原因：正则[0-9]+\.[0-9]+([eE][+-]?[0-9]+)?未覆盖整数部分为0的情况（如.5），也未处理e后无数字（如1e）的错误情形。
解决：拆分为两组规则，用flex的yymore()拼接：

[0-9]+\.([0-9]+)?([eE][+-]?[0-9]+)? { /* handle 123., 123.45, 123.45e-6 */ } \.[0-9]+([eE][+-]?[0-9]+)? { /* handle .45, .45e+2 */ } [0-9]+[eE][+-]?[0-9]+ { /* handle 123e-6 */ }

3.4 现象：关键字与标识符冲突，intx被误判为int+x

原因：flex按最长匹配原则，intx中int是关键字，但intx本身更长，若未将关键字规则置于标识符规则之前，则intx被当作ID。
解决：关键字规则必须严格前置，且显式终止：

"int" { return KEYWORD_INT; } "if" { return KEYWORD_IF; } /* ... all keywords ... */ [a-zA-Z_][a-zA-Z0-9_]* { yylval.str = strdup(yytext); return ID; }

3.5 现象：预处理器指令#include <stdio.h>被当作普通代码解析

原因：实验通常不实现预处理，但源码中存在#行，若未特殊处理，#会被当作文法错误。
解决：在INITIAL状态添加忽略行：

^"#".*\n { lineno++; /* skip preprocessor line, advance line counter */ }

4. 语法分析器攻坚：从Bison模板到手写递归下降的取舍逻辑

语法分析是编译流程的中枢，选型直接决定后续语义分析的难度。Bison（Yacc）生成LR(1)分析器，适合教学；但真实项目中，手写递归下降（Recursive Descent）因其可读性、可控性和调试友好性，成为工业界首选。本节不争论优劣，只说清楚：什么场景该用Bison，什么场景必须手写，以及手写时如何避免经典陷阱。

4.1 Bison不是银弹：何时该果断放弃

Bison适合语法高度规则、左递归可消除、冲突少的场景（如PL/0、TINY语言）。但一旦遇到以下情况，强行用Bison会付出巨大调试成本：

• 右结合运算符（如赋值a = b = c）：Bison默认左结合，需手动改写文法或用%right声明，但复杂表达式易出错；
• 上下文相关语法（如C语言中*p是解引用，int *p是声明）：Bison纯文法层无法区分，必须依赖词法分析器传入额外信息（如TYPE_NAMEtoken），增加耦合；
• 错误恢复弱：Bison报错后常直接abort，而手写解析器可在expect(SEMI)失败时跳过至下一个;，继续解析后续语句。

我的经验：如果实验要求支持if-else悬空问题（dangling else）、或需在语法分析阶段做简单类型推导（如auto x = 1;），立刻切换手写递归下降。Bison此时不是加速器，而是枷锁。

4.2 手写递归下降：用C实现一个可调试的Parser

以支持int a = 1 + 2 * 3;的声明语句为例，核心是运算符优先级的自然体现。我们不写BNF，直接写函数：

// parser.h typedef struct ASTNode ASTNode; struct ASTNode { enum { NODE_DECL, NODE_BINARY, NODE_INT } type; union { struct { char* name; ASTNode* init; } decl; struct { char op; ASTNode* left; ASTNode* right; } binary; int value; }; }; ASTNode* parse_program(); ASTNode* parse_declaration(); ASTNode* parse_expression(int prec); // prec: current precedence level ASTNode* parse_primary(); // parser.c ASTNode* parse_program() { ASTNode* node = malloc(sizeof(ASTNode)); node->type = NODE_PROGRAM; node->program.body = parse_declaration(); // assume single decl for demo return node; } ASTNode* parse_declaration() { expect(KEYWORD_INT); // consume 'int' char* name = expect(ID)->str; // consume identifier expect(ASSIGN); ASTNode* init = parse_expression(0); // start with lowest precedence expect(SEMI); ASTNode* node = malloc(sizeof(ASTNode)); node->type = NODE_DECL; node->decl.name = name; node->decl.init = init; return node; } // Pratt parsing: precedence climbing ASTNode* parse_expression(int prec) { ASTNode* left = parse_primary(); while (1) { int op_prec = get_operator_precedence(peek_token().type); if (op_prec < prec) break; // stop at lower precedence Token op = consume_token(); // consume '+', '-', etc. left = make_binary_node(op.type, left, parse_expression(op_prec + 1)); } return left; } ASTNode* parse_primary() { Token tok = peek_token(); if (tok.type == INT) { consume_token(); ASTNode* node = malloc(sizeof(ASTNode)); node->type = NODE_INT; node->value = tok.num; return node; } else if (tok.type == LPAREN) { consume_token(); ASTNode* expr = parse_expression(0); expect(RPAREN); return expr; } else { fprintf(stderr, "Syntax error: expected primary at line %d\n", tok.line); exit(1); } }

逻辑说明：

• parse_expression(int prec)是核心，采用Pratt解析法（precedence climbing），通过递归调用自身并传入更高precedence，天然实现*优先于+；
• peek_token()不消耗token，仅查看下一个；consume_token()才真正移进；expect(T)先peek再consume，失败则报错；
• make_binary_node()创建AST节点，left/right指针明确指向子树，为后续语义分析提供结构基础。

参数说明：

• prec参数初始为0，+和-设为10，*和/设为20，=设为5（右结合，需特殊处理）；
• get_operator_precedence()返回当前token的优先级，必须覆盖所有运算符，未定义则返回0；
• expect()函数内部必须检查peek_token().type，不匹配时打印详细位置（line/col）并exit，避免静默失败。

5. 语义分析与中间代码生成：用符号表和四元式打通“懂代码”到“会翻译”的最后一公里

词法和语法分析解决“代码长什么样”，语义分析解决“代码什么意思”，中间代码生成解决“怎么把它变成机器能懂的步骤”。这三步环环相扣，符号表是语义分析的基石，四元式是中间代码的通用载体。本节聚焦如何让这两者真正协同工作，而非各自为政。

5.1 符号表设计：不是哈希表，而是作用域栈上的动态映射

符号表不能是简单的char* -> Type哈希表，因为C语言有块作用域（{ int x; ... int x; }合法）。必须支持作用域嵌套、同名遮蔽、跨作用域查找。我采用“作用域栈+哈希表”混合结构：

// symbol.h typedef struct Symbol Symbol; struct Symbol { char* name; Type type; // enum { TYPE_INT, TYPE_VOID, ... } int is_function; // 1 if function, 0 if variable int offset; // stack offset for local var, 0 for global Symbol* next; // for hash chain }; typedef struct Scope Scope; struct Scope { Symbol** table; // hash table (size 101) int size; // hash table size Scope* parent; // outer scope }; Scope* current_scope; Scope* create_scope(Scope* parent) { Scope* s = malloc(sizeof(Scope)); s->table = calloc(101, sizeof(Symbol*)); s->size = 101; s->parent = parent; return s; } void enter_scope() { current_scope = create_scope(current_scope); } void exit_scope() { Scope* old = current_scope; current_scope = current_scope->parent; free_scope(old); // free all symbols in this scope } Symbol* lookup_symbol(char* name) { Scope* s = current_scope; while (s) { unsigned int hash = hash_string(name) % s->size; for (Symbol* sym = s->table[hash]; sym; sym = sym->next) { if (strcmp(sym->name, name) == 0) return sym; } s = s->parent; } return NULL; } void insert_symbol(char* name, Type type, int is_func) { if (lookup_symbol(name)) { fprintf(stderr, "Semantic error: redefinition of '%s' at line %d\n", name, lineno); exit(1); } unsigned int hash = hash_string(name) % current_scope->size; Symbol* sym = malloc(sizeof(Symbol)); sym->name = strdup(name); sym->type = type; sym->is_function = is_func; sym->offset = 0; // will set in codegen sym->next = current_scope->table[hash]; current_scope->table[hash] = sym; }

关键点：

• enter_scope()/exit_scope()在遇到{和}时调用，必须与语法分析器的AST节点生成同步；
• lookup_symbol()从current_scope向上查找，实现遮蔽；insert_symbol()只在当前作用域插入，不检查外层；
• hash_string()用DJB2算法，避免哈希碰撞过多。

5.2 四元式生成：从AST到(op, arg1, arg2, result)的确定性映射

四元式是中间代码的“普通话”，格式统一为(op, arg1, arg2, result)。生成规则必须与AST节点类型一一对应，且临时变量命名必须全局唯一、可追溯。以BinaryOp节点为例：

// ir.c int temp_counter = 0; char* new_temp() { char* name = malloc(10); sprintf(name, "t%d", temp_counter++); return name; } char* generate_ir(ASTNode* node) { switch (node->type) { case NODE_INT: { char* t = new_temp(); printf("%s = %d\n", t, node->value); return t; } case NODE_BINARY: { char* left = generate_ir(node->binary.left); char* right = generate_ir(node->binary.right); char* result = new_temp(); char* op_str; switch (node->binary.op) { case PLUS: op_str = "+"; break; case MINUS: op_str = "-"; break; case TIMES: op_str = "*"; break; default: op_str = "?"; } printf("%s = %s %s %s\n", result, left, op_str, right); return result; } case NODE_DECL: { // for 'int a = expr;', generate IR for expr, then assign to a char* init = generate_ir(node->decl.init); printf("%s = %s\n", node->decl.name, init); return node->decl.name; } default: fprintf(stderr, "IR generation error: unknown node type\n"); exit(1); } }

逻辑说明：

• new_temp()返回t0,t1,t2...，不重置计数器，保证全局唯一；
• generate_ir()递归遍历AST，每个节点返回其计算结果的临时变量名（如1+2返回t0，t0*3返回t1）；
• 对NODE_DECL，先生成初始化表达式的IR，再生成赋值语句，不生成a的声明语句（四元式不处理声明，只处理计算）。

参数说明：

• temp_counter为全局变量，不可在函数内static声明，否则多轮调用会重置；
• printf输出必须严格按(result, op, arg1, arg2)顺序，与标准四元式格式一致，方便后续优化器读取；
• NODE_BINARY中arg1和arg2顺序必须与AST中left/right一致，乘法交换律不影响，但减法/除法必须严格。

6. 实验报告的终极验证：用3个硬指标判断你的报告是否真有价值

一份合格的《编译原理实验报告》，不能止于“我实现了”，而要回答：“我实现的是否健壮？是否可解释？是否可演进？” 我用三个可量化的硬指标来验收——它们不来自评分标准，而来自真实工程场景的倒逼。

6.1 指标一：错误定位精度——报错行号与列号误差 ≤ 1

编译器报错若只说“syntax error”，等于没报。真正的价值在于：当输入int a = 1 + ;（缺少右操作数）时，你的parser必须精准指出line 1, column 12（+后的位置），而非笼统的line 1。验证方法：

• 准备10个典型错误用例（缺分号、括号不匹配、未闭合字符串、关键字拼错等）；
• 运行parser，捕获stderr输出；
• 用正则提取line (\d+), column (\d+)，与人工标注的真实错误位置比对；
• 10个用例中，9个以上误差≤1列，才算达标。

我的教训：早期用Bison时，错误位置常滞后1-2个token，因为Bison的yyerror()在归约失败后才触发。改用手写递归下降后，在expect(SEMI)失败时立即打印peek_token().line/col，精度飙升。错误位置不是附属功能，而是调试生命线。

6.2 指标二：中间产物可逆性——从IR反推源码的还原度 ≥ 80%

四元式是编译的“中间态”，但它不该是黑盒。一份高价值报告，必须证明IR忠实反映了源码意图。验证方法：

• 选取5个复杂表达式（如a = (b + c) * d - e / f）；
• 生成其四元式序列；
• 手动将四元式“翻译”回C表达式（按依赖关系拓扑排序）；
• 用字符串相似度算法（如Levenshtein距离）比对还原表达式与原表达式；
• 平均相似度≥80%，说明IR生成逻辑清晰、无歧义丢失。

例如原式a = b * c + d生成：

t1 = b * c t2 = t1 + d a = t2

还原为a = b * c + d，相似度100%；若生成a = b * c + d（省略临时变量），则丢失了计算顺序信息，还原度暴跌。

6.3 指标三：模块解耦度——替换lexer后，parser/semantic/irgen无需修改一行代码

这是检验架构设计的终极压力测试。当你把flex生成的lexer换成手写DFA lexer，或把递归下降parser换成LL(1) table-driven parser时，其他模块的源码、编译命令、测试用例应完全不变。验证清单：

不通过即重构：若发现parser.c里硬编码了"KEYWORD_INT"字符串，说明lexer与parser耦合过深，必须抽离为token.h常量。

最后说一句：我带过几届某高校编译原理实验课，见过太多报告堆砌大段Bison语法却说不清%left为何能解决移进-归约冲突；也见过手写parser的同学，因没加lineno++导致所有错误行号错位而通宵调试。编译原理实验的价值，不在“造出一个能跑的玩具”，而在“亲手拆开每一个齿轮，看清它为何转动、何时卡死、怎样修复”。这份报告，就是你拆解过程的全程录像带——帧帧可查，步步可验。希望帮到你。

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