从零开始的编译原理 on Lorn

[从零开始的编译原理][实验] Exp Chapter 2：从 Koopa IR 到 RISC-V

Tue, 06 Oct 2026 20:24:45 +0800

接下来，在本节中，我们将在上一节工作的基础上，让编译器进一步支持生成 RISC-V 汇编代码。

目前我们需要编译的 SysY 程序仍然非常简单：

1
2
3
4
5


int main()
{
 // 摊牌了，我是注释
 return 0;
}

上一节中，我们已经可以将它编译为如下的 Koopa IR：

1
2
3
4


fun @main(): i32 {
%entry:
 ret 0
}

而本节的目标，是继续完成从 Koopa IR 到 RISC-V 汇编的转换。例如生成：

1
2
3
4
5


 .text
 .globl main
main:
 li a0, 0
 ret

当然，根据具体的代码生成策略，也可能生成：

1
2
3
4
5
6


 .text
 .globl main
main:
 li t0, 0
 mv a0, t0
 ret

两种写法在这里的效果是一样的：最终都将整数 0 放入返回值寄存器 a0 中，然后从 main 函数返回。

具体生成哪一种形式，取决于我们的代码生成器如何处理中间结果和寄存器。对于当前这个非常简单的程序来说，显然没有必要额外使用临时寄存器，因此我们直接生成第一种形式即可。

目标代码生成

目前，我们的编译器已经完成了这样一条编译链：

1
2
3
4
5
6
7


SysY 源代码
 ↓
Lexer / Parser
 ↓
AST
 ↓
Koopa IR

接下来需要继续完成：

1
2
3
4
5


Koopa IR
 ↓
CodeGen
 ↓
RISC-V Assembly

上一章中，我们已经自己设计并实现了 Koopa IR 的数据结构。因此，这里的目标代码生成与之前实现 Printer 输出 Koopa IR 文本其实非常类似：

遍历 IR 数据结构，根据不同的 IR 节点输出对应的 RISC-V 指令。

例如：

1

ret 0

对应：

1
2


li a0, 0
ret

因此，从整体结构来看，CodeGen 同样可以采用 Visitor 风格的实现：依次访问 Program、Function、BasicBlock 和 Instruction，最终将每条 IR 指令翻译成对应的汇编指令。

不过，在开始实现之前，我们首先需要理解生成出来的这几行 RISC-V 汇编究竟在做什么。

对于：

1
2
3
4
5


 .text
 .globl main
main:
 li a0, 0
 ret

整体上主要完成了三件事情：

定义函数 main 的入口；
将函数返回值 0 放入规定的返回值寄存器；
执行函数返回。

因此，我们首先需要回答三个问题。

如何定义一个函数？

在高级语言中，我们习惯把函数理解成：

1
2
3
4


int main()
{
 return 0;
}

但从处理器的视角来看，函数本质上只是一段连续或逻辑关联的指令序列。

调用函数时，处理器跳转到这段指令序列的入口开始执行；函数执行结束时，再通过返回指令跳回调用者。

因此，在汇编层面，并不存在类似 C/C++ 中：

1

int main()

这样的“函数定义语法”。

我们真正需要做的，只是给这段指令的入口位置定义一个符号：

1

main:

这里的 main 是一个 label（标签）。汇编器会把它关联到当前位置对应的地址。之后，无论是链接器还是其他代码，都可以通过符号 main 找到这段代码的入口。

同时：

1

.globl main

用于声明 main 是一个全局符号，使这个符号可以被链接器看到。

而：

1

.text

则表示接下来的内容属于 .text 段，也就是程序的代码段。

因此：

1
2
3


 .text
 .globl main
main:

可以简单理解成：

接下来是一段代码，并且我们定义了一个可以被外部找到的函数入口 main。

至于函数如何返回，并不是函数标签本身负责的，而是函数内部生成的指令负责的。

如何在 RISC-V 中设置返回值？

函数调用不仅涉及“跳转到哪里”，还涉及调用者和被调用者之间如何传递参数、返回值，以及哪些寄存器需要保存等问题。

这些规则由 RISC-V Calling Convention（调用约定）规定。

对于整数返回值，RISC-V 使用：

作为返回值寄存器。

在 RV32 中，一个通用寄存器的宽度为 32 bit，因此 a0 和 a1 可以用于传递最多两个 XLEN 宽度的整数返回值。

不过对于我们现在的程序：

1
2
3
4


int main()
{
 return 0;
}

只有一个 int 类型返回值，因此只需要：

1

a0

也就是说：

1

return 0;

最终需要确保：

1

a0 = 0

随后再执行函数返回即可。

如何将整数加载到寄存器中？

接下来的问题就是：如何让：

1

a0 = 0

RISC-V 汇编器提供了一个非常方便的伪指令：

1

li rd, imm

其中：

rd 表示目标寄存器；
imm 表示立即数。

例如：

1

li a0, 0

表示：

将立即数 0 加载到寄存器 a0 中。

需要注意的是，li 是一个伪指令（pseudo-instruction），它并不一定直接对应某一条真实的 RISC-V 机器指令。

汇编器会根据立即数的大小，将它展开为一条或多条真正的 RISC-V 指令。例如对于较小的立即数：

1

li a0, 0

可以被展开成类似：

1

addi a0, zero, 0

至于具体如何展开，则交给汇编器处理即可。对于编译器前端和目前的简单代码生成器而言，我们直接生成 li 会方便很多。

函数最后的：

1

ret

同样也是一个伪指令。

它表示：

从当前函数返回到调用者。

其底层实际上可以展开为类似：

1

jalr zero, 0(ra)

其中 ra 保存了函数调用完成后应该返回的位置。

因此，我们生成：

1
2
3
4
5


 .text
 .globl main
main:
 li a0, 0
 ret

其含义可以完整地理解为：

1
2
3
4
5
6


 .text # 接下来的内容放入代码段
 .globl main # 将 main 声明为全局符号

main: # main 函数的入口
 li a0, 0 # 将返回值 0 放入 a0
 ret # 返回调用者

这就完成了：

1
2
3
4


int main()
{
 return 0;
}

最基本的目标代码生成。

接下来，我们就可以仿照上一节 Printer 的实现方式，设计一个 CodeGen 类：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


class CodeGen
{
public:
 std::string Generate(const Program& program) const;

private:
 void Visit(const Function& func, std::ostream& out) const;
 void Visit(
 const BasicBlock& block,
 const std::string& func_name,
 std::ostream& out
 ) const;

 void Visit(const Instruction& inst, std::ostream& out) const;
 void Visit(const Return& ret, std::ostream& out) const;

 void LoadOperand(
 const IRValue& value,
 const char* reg,
 std::ostream& out
 ) const;
};

它的整体结构和 Printer 非常相似。

我们仍然按照：

1
2
3
4
5
6
7


Program
 ↓
Function
 ↓
BasicBlock
 ↓
Instruction

这样的层次遍历 IR。

区别在于，之前的 Printer 只是把 IR 数据结构重新打印为 Koopa IR 文本，例如：

1

ret 0

而现在的 CodeGen 需要真正考虑目标机器的语义。

例如面对：

1

ret 0

我们不能简单地输出：

1

ret 0

而需要知道 RISC-V 的调用约定规定返回值应当放在 a0 中，因此要生成：

1
2


li a0, 0
ret

也就是说：

Printer 主要关心 IR 的语法，而 CodeGen 开始需要关心目标架构的 ABI、寄存器和指令。

因此，我们额外定义：

1

LoadOperand(...)

负责将一个 IR 操作数加载到指定寄存器。

目前我们的 IR 非常简单，操作数只有整数立即数，因此 LoadOperand 暂时只需要处理：

1

IRInteger

未来随着 IR 中出现临时变量、二元表达式、局部变量等内容，这个函数才会逐渐涉及寄存器和栈上的数据。

具体实现如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


std::string CodeGen::Generate(const Program& program) const
{
 std::ostringstream out;

 out << " .text\n";

 for (const auto& func : program.funcs)
 {
 Visit(*func, out);
 }

 return out.str();
}

Generate 是整个目标代码生成过程的入口。

首先：

1

out << " .text\n";

声明接下来生成的是代码段。

然后依次遍历程序中的所有函数：

1
2
3
4


for (const auto& func : program.funcs)
{
 Visit(*func, out);
}

虽然目前我们的程序中只有一个：

1

main

但是从数据结构和代码生成器的设计上，我们仍然按照“一个程序可以包含多个函数”的方式实现。

接下来处理函数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


void CodeGen::Visit(const Function& func, std::ostream& out) const
{
 out << " .globl " << func.name << "\n";
 out << func.name << ":\n";

 for (const auto& block : func.bbs)
 {
 Visit(*block, func.name, out);
 }

 out << "\n";
}

对于每个函数，首先生成：

1
2


.globl main
main:

分别对应：

1
2


out << " .globl " << func.name << "\n";
out << func.name << ":\n";

随后遍历函数中的所有基本块：

1
2
3
4


for (const auto& block : func.bbs)
{
 Visit(*block, func.name, out);
}

目前我们的 main 只有一个基本块：

1

%entry

并且不存在跳转，因此还不需要真的为 %entry 生成汇编标签。

后面当程序出现：

1
2


if
while

等控制流结构时，一个函数中会出现多个基本块。此时我们就需要为不同的基本块生成标签，例如：

1
2
3
4


main_entry:
main_then:
main_else:
main_end:

这里将 func.name 一并传给 Visit(BasicBlock)，也正是为了给后续生成基本块标签预留上下文。

目前基本块本身只需要继续遍历其中的指令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


void CodeGen::Visit(
 const BasicBlock& bb,
 const std::string& func_name,
 std::ostream& out
) const
{
 for (const auto& inst : bb.insts)
 {
 Visit(*inst, out);
 }
}

接下来根据指令类型进行分派：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


void CodeGen::Visit(const Instruction& inst, std::ostream& out) const
{
 switch (inst.kind)
 {
 case ValueKind::Return:
 {
 Visit(static_cast<const Return&>(inst), out);
 return;
 }

 default:
 {
 throw std::runtime_error(
 "unsupported instruction kind: " +
 std::to_string(static_cast<int>(inst.kind))
 );
 }
 }
}

目前我们的 IR 中唯一可能出现的指令就是：

1

Return

因此只需要处理：

1

ValueKind::Return

即可。

对于：

1

ret 0

对应的 IR 大致可以理解为：

1
2
3


Return
└── operand
 └── Integer(0)

因此在处理 Return 时：

1
2
3
4
5


void CodeGen::Visit(const Return& ret, std::ostream& out) const
{
 LoadOperand(*ret.operand, "a0", out);
 out << " ret\n";
}

我们首先调用：

1

LoadOperand(*ret.operand, "a0", out);

含义就是：

将 return 的操作数加载到返回值寄存器 a0。

随后：

1

out << " ret\n";

生成函数返回指令。

最后实现 LoadOperand：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


void CodeGen::LoadOperand(
 const IRValue& value,
 const char* reg,
 std::ostream& out
) const
{
 switch (value.kind)
 {
 case ValueKind::Integer:
 {
 const auto& integer =
 static_cast<const IRInteger&>(value);

 out << " li " << reg << ", "
 << integer.value << "\n";

 return;
 }

 default:
 {
 throw std::runtime_error(
 "unsupported value kind: " +
 std::to_string(static_cast<int>(value.kind))
 );
 }
 }
}

目前 LoadOperand 只需要处理整数立即数。

例如：

1

IRInteger(0)

并要求加载到：

1

a0

最终就会生成：

1

li a0, 0

于是整个调用过程就是：

1
2
3
4
5
6
7
8
9


Generate(Program)
 ↓
Visit(Function main)
 ↓
Visit(BasicBlock entry)
 ↓
Visit(Return)
 ↓
LoadOperand(Integer(0), a0)

最终输出：

1
2
3
4
5


 .text
 .globl main
main:
 li a0, 0
 ret

至此，我们的编译器已经第一次完成了一条完整的编译链：

1
2
3
4
5
6
7


SysY
 ↓
AST
 ↓
Koopa IR
 ↓
RISC-V Assembly

虽然目前支持的程序只有最简单的：

1
2
3
4


int main()
{
 return 0;
}

但这里建立起来的 CodeGen 框架之后基本可以继续沿用。

随着后面的 SysY 语法逐渐复杂，我们主要需要不断扩展：

1

Visit(...)

来支持新的 IR 指令，并逐步完善：

1

LoadOperand(...)

对临时变量、寄存器和栈上数据的处理。

[从零开始的编译原理][理论] Chapter 2：语法分析

Sat, 03 Oct 2026 15:32:40 +0800

这一节我们主要学习的是语法分析。

语法分析

在进行完词法分析后，我们得到了一组Token序列，而语法分析则用来分析这些token之间的结构关系。

例如我们有一个表达式:

1

a = b + 3 * 4;

经过词法分析后，我们可以得到:

1

ID(a) = ID(b) + NUM(3) * NUM(4);

那么它应该被解析为:

1

b + (3 * 4)

对应这个AST:

1
2
3
4
5


 +
 / \
 b *
 / \
 3 4

语法分析器同样有三种实现方法：

语法分析器生成器
手写语法分析器
自动化语法分析器

我们按照同样的顺序，介绍如何用语法分析器生成器来进行语法分析，以及自动化语法分析器背后的基本原理。

语法分析器生成器

在本节中，我们继续用antlr来设计一个类C 语言的grammer: Cymbol.g4( github实现参考，我们下面的可能有细微的不同),这一次，我们重点关心其中的语法部分。

在生成语法分析器的同时，我们还会利用这个分析器去抽取函数调用图.

Cymbol 的语法规则实现

接下来我们先来尝试用antlr来描述Cymbol.g4这个语言的语法结构，我们采用从上到下的描述顺序。

首先，整个程序，我们可以认为是有若干个变量声明和函数声明构成的，因此我们可以写出第一条语法规则:

1

prog : (varDecl | functionDecl)* EOF ;

那么接下来我们就需要去写变量声明和函数声明的语法:

变量声明写作:

1
2


varDecl : type ID ('=' expr)? ';' ;
type : 'int' | 'double' | 'void' ;

其中括号中的内容是变量初始值声明，这是一个可选的，因此我们括号后面用？描述

函数声明则写作:

1
2
3


functionDecl : type ID '(' formalParameters ? ')' block ;
formalParameters : formalParameter (',' formalParameter)* ;
formalParameter : type ID ;

其中，formalParameters还可以写作递归形式:

1
2
3


formalParameters : formalParameters ',' formalParameter
 | formalParameter
 ;

接下来我们看看函数体block的语法规则:

1
2
3
4
5
6
7
8


block : '{' stat* '}' ;
stat : block
 | varDecl
 | 'if' expr 'then' stat ('else' stat)?
 | 'return' expr? ';'
 | expr '=' expr ';'
 | expr ';'
 ;

其中 stat定义的第一行中调用了block，而block又调用了stat，这是一种互递归。

接下来我们重点看看一个expr也就是表达式的语法规则应该是怎样的:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


expr : ID '(' exprList ? ')' # 表达函数调用
 | expr '[' expr ']' # 表达下标
 | '-' expr
 | '!' expr
 | expr '^' expr
 | expr ('*' | '/') expr
 | expr ('+' | '-') expr
 | expr ('==' | '!=') expr
 | '(' expr ')'
 | ID
 | INT;
exprList : expr (',' expr)* ;

一些问题

在上一小节中，我们初步完成了Cymbol语言的语法规则定义，但是上述语法规则会存在一定的问题:

1

if a then if b then c else d

我们现在用上面的语法规则去解析这个语句，发现有两种解析方法:

1
2


if a then [if b then c] else d
if a then [if b then c else d]

这就是语言的二义性，在设计语法分析器时，我们应该消除这种二义性。

这种二义性叫做Dangling Else二义性

一种消除的方式是改写上述匹配规则:

简单来说，我们规定else总是和最近的，尚未匹配else的if匹配。

为了体现这种规则，我们把语句分为两类: matched和open,那么此时文法可以写作:

1
2
3
4
5
6
7
8
9


stat : matched_stat | open_stat;

matched_stat : 'if' expr 'then' matched_stat 'else' matched_stat
 | expr
 ;
 
open_stat : 'if' expr 'then' stat
 | 'if' expr 'then' matched_stat 'else' open_stat
 ;

在这种文法下，我们上面的例子，就只会匹配第二种解析方法了。

而在antlr这样的语法分析器生成器中，则巧妙的用最前优先匹配原则解决了这个问题。

除了悬空的Else带来的二义性外，运算符的结合性也有可能带来二义性:

1
2
3
4


expr : expr '*' expr
 | expr '-' expr
 | DIGIT
 ;

例如1-2-3,此时可能是(1-2)-3也可以被识别为1-(2-3)这实际上是一个左结合，右结合的问题，由于大部分的运算符都是左递归的，因此像antlr这样的语法分析器生成器都是默认左结合的，那自然就会带来一个问题，那右递归的运算符怎么办？
一般来说，右递归的运算符大多都是前缀运算符或后缀运算符，这种运算符只有一种匹配规则，因此不太需要考虑二义性，而真正需要考虑二义性的就是像^这样的右递归运算符。

对于这一类需要右结合的运算符，在antlr中，我们可以手动指定结合的方式:

1
2
3
4


expr : '!' expr
 | <assoc = right> expr '^' expr
 | DIGIT
 ;

其他语法分析器生成器也存在类似的手动指定左/右结合的功能。

利用语法分析器得到函数调用图

通过语法分析器，我们最终可以得到一个AST，而antlr提供了一个接口:ParseTreeWalker,它可以以DFS的方式自动遍历整个AST，并且我们可以利用Listener来负责监听进入，退出节点的事件。

假设我们要得到函数调用图，那么一个必要的事情就是得到每个函数的名称。那利用Listener就很好实现这一点了，我们只需要每次监听到事件:functionDecl Enter就记录下节点的函数名称就能获取所有的函数名称了。

得到了所有函数的名称之后，我们还需要得到函数之间的调用关系，根据我们的语法规则，我们可以知道，函数调用语句会被语法规则:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


expr : ID '(' exprList ? ')'
 | expr '[' expr ']'
 | '-' expr
 | '!' expr
 | expr '^' expr
 | expr ('*' | '/') expr
 | expr ('+' | '-') expr
 | expr ('==' | '!=') expr
 | '(' expr ')'
 | ID
 | INT;
exprList : expr (',' expr)* ;

识别，因此我们只需要识别到函数调用事件之后，由调用函数向被调用函数连一条边即可。但是比较麻烦的点在于，除了函数调用，expr还有多条解释规则，而Listener并不会对上述规则作区分，我们能看到的只有expr Enter以及expr Exit,要在此基础上识别出函数调用，我们还需要补充大量的if语句做判断，这显然不是我们希望的。

事实上，在antlr中，是支持对每条规则用#来加标签的:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


expr : ID '(' exprList ? ')' # functionCall
 | expr '[' expr ']' 
 | '-' expr
 | '!' expr
 | expr '^' expr
 | expr ('*' | '/') expr
 | expr ('+' | '-') expr
 | expr ('==' | '!=') expr
 | '(' expr ')'
 | ID
 | INT;
exprList : expr (',' expr)* ;

这样，我们就可以通过Listener得到事件:functionCall Enter/Exit了。

语法分析的基本原理（1） CFG

我们先来看文法的组成:

1

functionDecl : type ID '(' formalParameters? ')' block;

每个文法规则都由:分隔为两部分，其中前面部分我们称为头部(Head),后者为规则体(Body)。整个规则我们称作产生式(Production).

每个产生式的头部都是非终结符。而所有没有出现在头部的符号，我们称作终结符，他们对应于我们词法分析器中产生的词法单元。

这种文法，我们称作上下文无关文法（Context-Free Grammar CFG）。

一个上下文无关文法通常写作:

$$ G = (V,T,P,S) $$

分别代表:

V：非终结符
T：终结符
P：产生式
S：开始符号

用数学符号表示就是:

$$ A\in N\to \alpha \in (T \cup N)^* $$

接下来我们介绍一下CFG的语义:

这里会涉及到几个基本概念:

推导：推导顾名思义就是用产生式对终结符进行替换，例如:

我们用规则:

$$ E \to E + E | E * E | (E) | -E | id $$

从E得到字符串：-(id + id)

那么推导的流程我们可以写作 :

$$ E \to -E \to -(E)\to-(E+E)\to -(id+E)\to-(id + id) $$

这其中还会涉及到一个最左推导和最右推导的概念，二者的区别在于，前者在推导时总是选择最左侧的非终结符进行推导，而后者则是选择最右侧的非终结符。

另外，我们会标记:

$E \Rightarrow -E $：经过一步推导得出
$E\xRightarrow{+}-(id+E)$：经过一步或多步推导得出
$E\xRightarrow{*}-(id+E)$：经过零步或多步推导得出

句型: 如果 $S \xRightarrow{*} \alpha,\alpha \in (T\cup N)^*$,则称 $\alpha$是文法G的一个句型。
句子：如果 $S \xRightarrow{*} \omega,\omega \in T*$,则称 $\omega$为文法G的一个句子
文法G的语言L(G)是它能推导出的所有句子构成的集合 : $L(G) = \{\omega | S\xRightarrow{*} \omega\}$

关于文法G，我们主要关心两个主要问题:

Membership 问题，即给定一个字符串，该字符串是否属于该文法产生的语言L(G)？
L(G)究竟是什么？

其中，第一个问题就是编译器语法分析器的任务，为输入的词法单元流寻找推导，构建语法分析树或者报错。

而第二个问题则是程序设计者需要考虑的问题。

这个问题通常体现在这样的题目上: 请给出文法，满足: $\{x \in \{a,b\}^*| x中a,b数目相同\}$

一个可能的文法是: $V\to VV|aVb|bVa|\epsilon$

下面简单证明一下为什么？

我们可以先证明文法生成的串一定满足a,b数目相同:

我们记: $\#_a(x)$表示串x中字符a的数目。

我们证明采用归纳法。

$V \Rightarrow \epsilon$,显然，此时满足 $\#_a(\epsilon) = \#_b(\epsilon)=0$
若 $V\xRightarrow{*} x$,且x中字符a和b的数目相同，那么有: $V\Rightarrow aVb\xRightarrow{*}axb$,同时增加一个a和一个b，所以仍然相同，同理bVa以及VV仍然成立。

所以我们有: $L(G)\subseteq L$

接下来证明所有a,b数目相同的字符串都能被这个文法生成

对串长 $|x|$做归纳。

若$|x|=0$，则 $x=\epsilon$，有 $V \Rightarrow \epsilon$

假设所有长度小于n，且有: $\#_a(x) = \#_b(x)$的串都能由V生成。

考虑长度为n的串$x = x_1x_2\dots x_n$,且有 $\#_a(x) = \#_b(x)$。

首先讨论首尾字符不同的串，比如 x=ayb,由于整个x中a,b数目相同，去掉一个a和一个b后，y中仍然满足:

$\#_a(y) = \#_b(y)$.由归纳假设 $V \xRightarrow{*} y$.

因此 $V \Rightarrow aVb \xRightarrow{*}ayb=x$,若x=bya，同理。

然后考虑首尾字符相同的串，我们假设首尾字符都是a，且定义前缀的差值:

$$ d(k) = \#_a(x_1\dots x_k) - \#_b(x_1\dots x_k) $$

因为第一个字符是a所以有: $d(1)=1$,而最后一个字符为a，因此 $d(n-1)=-1$,而 $d(k)$每读一个字符只会变化+1或者-1。因此从 $d(1)=1$到 $d(n-1)=-1$的过程中肯定存在某个k满足: $d(k)=0$.

于是我们可以把字符串x分为:$x=yz$,其中y，z都非空，且分别满足:

$$ \#_a(y) = \#_b(y),\#_a(z)=\#_b(z) $$

又因为: $|y|,|z| < |x|$,由归纳假设我们知道:

$$ V\xRightarrow{*} y,V\xRightarrow{*}z $$

因此使用 $V \Rightarrow VV$,有:

$$ V\Rightarrow VV\xRightarrow{*}yz=x $$

对于首尾为b的串同理。因此，我们证明了:

$$ L \subseteq L(G) $$

综上

$$ L(G) = \{x\in\{a,b\}^*|\#_a(x)=\#_b(x)\} $$

语法分析的基本原理（2） LL

接下来我们重点考虑一下和我们语法分析器背后原理相关的问题：
Membership 问题，即给定一个字符串，该字符串是否属于该文法产生的语言L(G)

我们语法分析要做的事情，无非就是根据词法单元流构建语法分析树。在构建时，我们有两种思路，自顶向下和自底向上。

我们先来介绍第一种: 自顶向下的，递归下降的，基于预测分析表的，适用于LL(1)文法的LL(1)语法分析器。

其中自顶向下就是说我们在构建语法分析树时，是从根节点（文法的起始符号）往叶节点（词法单元）构建的。而中间每个中间节点表示对某个非终结符应用某个产生式进行推导。

而递归下降就是说，我们会为每个非终结符写一个递归函数，内部按需调用其他非终结符对应的递归函数，下降一层。

我们以下面这个文法的匹配来展示一下递归下降的过程:

$S \to F,S\to (S+F),F\to a$,匹配的文本是:((a+a)+a)

我们从起始符号S开始，首先第一步显然是匹配文法: $S\to (S+F)$

接下来遍历目前的词法单元，对于终结符直接跳过，否则进行递归展开，比如我们遇到第一个S时，将其展开: $S\to (S+ F)$,而第一个F时， $F\to a$,从而得到串: $((S+F)+a)$

按照上一步的流程，不断展开非终结符，最终匹配((a+a)+a)

那么在语法分析的过程中，自然就会产生一些问题，应该选择哪个终结符进行展开？应该选择采用哪个产生式进行推导？

对于LL(1)语法分析器而言，我们在推导的每一步都是选择最左边的非终结符进行展开。

而对于第二个问题，我们在LL(1)语法分析器中，通常借助预测分析表确定:

在上面的例子中，我们会通过某种算法得到如下预测分析表:

	(	)	a	+	$
S	2		1
F			3

这张表指明了每个非终结符在面对不同的词法单元或文件结束符时，该选择哪个产生式或者报错。

有了这张表，匹配就很简单了，我们只需要当需要对非终结符进行推导时，看看此时匹配的串的非终结符，然后选择相应的规则进行推导即可。

而重点是，我们如果根据文法，构建出预测分析表。

我们定义: $\text{FIRST}(\alpha)$是可以从 $\alpha$推导得到的句型的首个终结符的集合。形式化定义为:

$$ \text{FIRST}(\alpha)=\{ t\in T \cup \{\epsilon\} | \alpha \xRightarrow * t\beta \lor \alpha \xRightarrow * \epsilon \} $$

我们定义: $\text{FOLLOW}(A)$是可能在某些句型中紧跟在A右侧的终结符集合。形式化定义为:

$$ \text{FOLLOW}(A) = \{t\in T \cup \{\$\} | \exist s. S\xRightarrow* s \triangleq \beta At\gamma \} $$

我们接下来看如何计算这两个集合。

我们这样计算每个符号X的 $\text{FIRST}$集合:

若X是终结符，那么 $\text{FIRST}(X) = X$;

若X是非终结符，那么 $\text{FIRST}(X) \leftarrow \text{FIRST}(X)\cup \{\text{FIRST}(Y_1) / \epsilon\}$,其中 $X \to Y_1Y_2\dots Y_k$

另外，对于 $Y_2-Y_k$,若 $\epsilon \in L(Y_1,\dots,Y_i)$,那么有: $\text{FIRST}(X) \leftarrow \text{FIRST}(X) \cup \{\text{FIRST}(Y_i) / \epsilon\}$

特别地，若: $\epsilon \in L(Y_1,\dots,Y_k)$,那么 $\text{FIRST}(X) \leftarrow \text{FIRST}(X) \cup \{ \epsilon\}$

我们以下面的文法进行一次 $\text{FIRST}(X)$计算的演示(为了方便，我们用F(x)代替):

$$ (1) X \to Y, (2)X \to a,(3)Y\to \epsilon,(4)Y\to c,(5)Z\to d,(6)Z\to XYZ $$

我们先算 F(x),我们根据文法 $X\to Y$知道，我们需要先算F(Y).

由文法 $Y\to \epsilon,Y\to c$我们可以知道: $F(Y) = \{c,\epsilon\}$

计算完F(Y)后，我们可以进一步得到 $F(X) = \{a,c,\epsilon\}$，其中F(X)包含 $\epsilon$则是根据最后一条规则

最后我们计算F(Z),首先由 $Z\to d$，我们有 $\{d\}\subseteq F(Z)$,再看: $Z\to XYZ$

根据计算方法，我们先看X，此时我们有:
$F(Z)\leftarrow F(Z) \cup \{F(X) / \epsilon\} = \{a,c,d\}$

而由于 $X \Rightarrow \epsilon$,因此我们还需要看Y，此时我们得到 $\{a,c,d\}\subseteq F(Z)$,而由于Y也可以推出 $\epsilon$

因此我们最后还需要看Z，就得到了: $F(Z) = \{a,c,d\}$

需要注意的是，Z推不出 $\epsilon$，因此F(Z)中并不会含有它。

我们这样计算每个符号X的 $\text{FOLLOW}$(X)

若X是开始符号，那么有: $\text{FOLLOW}(X)\leftarrow \text{FOLLOW}(X)\cup \{\$\}$

若X是某个产生式右部的最后一个符号： $A \to \alpha X$： $\text{FOLLOW}(X)\leftarrow \text{FOLLOW}(X) \cup \text{FOLLOW}(A)$

若X是某个产生式的右部的中间的一个符号: $A\to \alpha X \beta$: $\text{FOLLOW}(X)\leftarrow \text{FOLLOW}(X)\cup (\text{FIRST}(\beta) / \{\epsilon\})$

特别地，若此时 $\epsilon \in \text{FIRST}(\beta)$,那么 $\text{FOLLOW}(X)\leftarrow \text{FOLLOW}(X)\cup \text{FOLLOW}(A)$

还是一样，我们以上面的文法为例，展示 $\text{FOLLOW}$集合的计算方法。

我们首先处理开始符号X，因为X是开始符号，我们显然有：

$\$ \in \text{FOLLOW}(X)$,所以目前： $\text{FOLLOW}(X) = \{\$\}$

接下来根据生产式: $X\to Y$，以及规则2，我们有: $\text{FOLLOW}(X)\subseteq \text{FOLLOW}(Y)$

因此目前: $\text{FOLLOW}(Y) = \{\$\}$

接下来看 $Z\to XYZ$.

对X而言，后面跟着YZ，所以要把 $\text{FIRST}(YZ) -\{\epsilon\}$,加入到 $\text{FOLLOW}(X)$中，因此我们需要计算:

$$ \text{FIRST}(YZ) = \{ a,c,d\} $$

因此: $\text{FOLLOW}(X) = \{\$,a,c,d\}$

对于Y而言，后面跟着Z，所以有:

$\text{FIRST}(Z) -\epsilon \subseteq \text{FOLLOW}(Y)$,而: $\text{FIRST}(Z) = \{a,c,d\}$

因此: $\text{FOLLOW}(Y) = \{\$,a,c,d\}$

而Z根据规则1知道是一个空集。

得到了FIRST集和FOLLOW集后，我们可以开始构造给定文法的预测分析表了。

通常而言，预测分析表写作: M[A,a],其中行为非终结符A，列尾终结符a，单元格内则填写应该选择哪个产生式。

填表规则只有两条。

对于产生式 $A\to \beta$

若 $a\in \text{FIRST}(\beta)-\{\epsilon\}$那么有: $M[A,a] = A\to \beta$;

若 $\epsilon \in \text{FIRST}(\beta)$,那么对于所有的: $b\in \text{FOLLOW}(A)$都有: $M[A,b] = A\to \beta$.

在实际计算中我们通常会先计算产生式 $A\to\beta$的 $\text{SELECT}$集合

我们定义: $\text{SELECT}(A\to\beta)$

若： $\epsilon \notin \text{FIRST}(\beta)$,那么 $\text{SELECT}(A\to\beta) = \text{FIRST}(\beta)$

若： $\epsilon \in \text{FIRST}(\beta)$,那么 $\text{SELECT}(A\to \beta) = (\text{FIRST}(\beta)-\{\epsilon\})\cup \text{FOLLOW}(A)$

得到 $A\to\beta$的SELECT集后，对该集合中每一个终结符a，把生产式 $A\to\beta$填入M[A,a]

还是上面那个例子，我们来手算一遍:

我们知道:

$$ \begin{aligned} (1)\quad &X\to Y\\ (2)\quad &X\to a\\ (3)\quad &Y\to \epsilon\\ (4)\quad &Y\to c\\ (5)\quad &Z\to d\\ (6)\quad &Z\to XYZ \end{aligned} $$$$ \begin{aligned} FIRST(X)&=\{a,c,\epsilon\}\\ FIRST(Y)&=\{c,\epsilon\}\\ FIRST(Z)&=\{a,c,d\} \end{aligned} $$$$ \begin{aligned} FOLLOW(X)&=\{a,c,d,\$\}\\ FOLLOW(Y)&=\{a,c,d,\$\}\\ FOLLOW(Z)&=\varnothing \end{aligned} $$

那么对于产生式（1） $X\to Y$,因为: $\text{FIRST}(Y) = \{c,\epsilon\}$,其中包含了 $\epsilon$，因此:

$$ \text{SELECT}(X\to Y) = \{a,c,d,\$\} $$

对于产生式（2） $X \to a$,这里 $\text{FIRST}(a) = \{a\}$，不包含 $\epsilon$,因此: $\text{SELECT}(X\to a) =\{a\} $

按照同样的思路，我们可以求出每个产生式的 $\text{SELECT}$集，从而得到最终的预测分析表:

非终结符	a	c	d	$
X	(1), (2)	(1)	(1)	(1)
Y	(3)	(3), (4)	(3)	(3)
Z	(6)	(6)	(5), (6)	error

[从零开始的编译原理][实验] Exp Chapter 1：从 SysY 到 Koopa IR

Tue, 29 Sep 2026 20:23:03 +0800

接下来，我们正式开始实现自己的编译器。

本阶段的目标是先完成一个最小可用版本：让编译器能够处理一个简单的 main 函数，并生成对应的 Koopa IR。

一个完整编译器的典型流程大致如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


词法分析
-> 语法分析
-> AST
-> 语义分析
-> 带有类型 / 符号信息的 AST
-> IR 生成
-> 优化
-> 指令选择
-> 寄存器分配
-> 指令调度

其中，词法分析、语法分析和 AST 构建属于编译器前端；

IR 生成通常位于前端与中端的衔接位置，而后续的优化、指令选择、寄存器分配和指令调度则会逐步进入编译器中端和后端。

根据指导书的安排，本次实验暂时不会实现完整的编译器流程，而是先完成从源代码到 Koopa IR 的这一部分，也就是：

1
2
3
4
5


源代码
-> 词法分析
-> 语法分析
-> AST
-> IR 生成

通过这一阶段，我们可以先打通一个最基本的编译流程，再在后续实验中逐步加入更完整的语义分析、优化以及代码生成等功能。

词法分析 & 语法分析

首先来看编译器前端最基础的两个阶段：词法分析（Lexical Analysis）和语法分析（Syntax Analysis）。

在本实验中，我们并不打算从零手写词法分析器和语法分析器，而是分别使用 Flex 和 Bison 来自动生成它们。我们只需要根据 SysY 的词法和语法规范，描述各种 Token 的形式以及程序的文法结构，之后 Flex 和 Bison 就可以据此生成对应的分析器。

SysY 的部分词法 / 语法规范

在本章中，我们暂时只实现一个能够处理 main 函数和 return 语句的简单编译器。也就是说，目前我们的编译器只需要能够处理类似下面这样的 SysY 程序：

1
2
3
4


int main() {
 // 注释也应该被忽略
 return 0;
}

最终，我们希望将它编译成对应的 Koopa IR：

1
2
3
4


fun @main(): i32 {
%entry:
 ret 0
}

在真正开始编写 Flex 和 Bison 代码之前，我们先来看一下这一阶段需要处理的 SysY 词法和语法规范。

词法规范主要描述源代码中存在哪些 Token，以及每种 Token 长什么样。例如：

1
2
3


int main() {
 return 0;
}

经过词法分析以后，大致可以得到：

1

INT IDENT '(' ')' '{' RETURN INT_CONST ';' '}'

其中，main 和 0 除了 Token 类型之外，还需要携带它们自身的值。

SysY 中标识符 IDENT 的规范如下：

1
2
3


identifier ::= identifier-nondigit
 | identifier identifier-nondigit
 | identifier digit;

其中 identifier-nondigit 为下划线 _、小写英文字母或大写英文字母，digit 为数字 0 到 9。

换句话说，标识符的首字符只能是字母或下划线，后续字符还可以包含数字，因此可以使用正则表达式：

1

[a-zA-Z_][a-zA-Z0-9_]*

来描述。

SysY 中的整型常量记作 INT_CONST，可以采用十进制、八进制或十六进制表示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


integer-const ::= decimal-const
 | octal-const
 | hexadecimal-const;

decimal-const ::= nonzero-digit
 | decimal-const digit;

octal-const ::= "0"
 | octal-const octal-digit;

hexadecimal-const ::= hexadecimal-prefix hexadecimal-digit
 | hexadecimal-const hexadecimal-digit;

hexadecimal-prefix ::= "0x" | "0X";

其中，nonzero-digit 为数字 1 到 9，octal-digit 为数字 0 到 7，hexadecimal-digit 为数字 0 到 9 或大小写字母 a-f。

例如：

1
2
3


123 十进制
077 八进制
0xFF 十六进制

SysY 中的注释规则与 C 语言基本一致：

单行注释以 // 开始，一直到换行符结束；
多行注释以 /* 开始，直到第一次出现 */ 时结束。

注释在后续编译阶段中没有意义，因此词法分析器识别出注释之后，可以直接将它们丢弃。

目前我们只需要支持如下语法：

1
2
3
4
5
6
7
8


CompUnit ::= FuncDef;

FuncDef ::= FuncType IDENT "(" ")" Block;
FuncType ::= "int";

Block ::= "{" Stmt "}";
Stmt ::= "return" Number ";";
Number ::= INT_CONST;

其中，开始符号为 CompUnit。

EBNF 介绍

EBNF，即 Extended Backus–Naur Form（扩展巴科斯范式），是一种用于描述编程语言语法的形式化方法。

基于 SysY 的 EBNF，我们可以从指定的开始符号出发，通过不断应用产生式规则，推导出所有符合该语法的程序。

EBNF 由若干条类似下面的规则组成：

1

A ::= B;

它表示，当我们遇到 A 时，可以按照这条规则将 A 替换成 B，这个过程称为一次推导（Derivation）。

例如：

1

CompUnit ::= FuncDef;

表示：

1

CompUnit

可以被替换成：

1

FuncDef

像 CompUnit、FuncDef、FuncType、Block、Stmt、Number 这样还能继续按照某条产生式展开的符号，被称为非终结符（Non-terminal）。

我们从开始符号 CompUnit 出发：

1

CompUnit

根据：

1

CompUnit ::= FuncDef;

得到：

1

FuncDef

继续根据：

1

FuncDef ::= FuncType IDENT "(" ")" Block;

得到：

1

FuncType IDENT "(" ")" Block

再利用：

1

FuncType ::= "int";

可以得到：

1

"int" IDENT "(" ")" Block

继续展开 Block、Stmt 和 Number，最终得到：

1

"int" IDENT "(" ")" "{" "return" INT_CONST ";" "}"

此时已经没有符号可以继续按照产生式展开。像 "int"、IDENT、"("、INT_CONST 这样的符号，就称为终结符（Terminal）。

这些终结符基本上就对应词法分析器产生的 Token。

因此可以粗略地理解为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


源代码
 │
 ▼
词法分析
 │
 ▼
Token / 终结符
 │
 ▼
语法分析
 │
 ▼
按照文法规则组合成程序结构

Flex 教程

在 C++ 中，我们使用 Flex 生成词法分析器。

Flex 主要负责描述 EBNF 中的终结符，也就是描述每种 Token 的形式，并在识别出 Token 后返回对应的类型和语义值。Token 的形式通常可以使用正则表达式来描述。

首先在 src 目录下创建：

1

sysy.l

Flex 文件大致被两个 %% 分成三个区域：

1
2
3
4
5


定义区
%%
规则区
%%
用户代码区

定义区位于第一个 %% 之前，主要用于设置 Flex 选项、插入 C++ 代码，以及定义可以复用的正则表达式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


%option noyywrap
%option nounput
%option noinput

%{

#include <cstdlib>
#include <string>

// Flex 需要使用 Bison 中定义的 Token 和 yylval
#include "sysy.tab.hpp"

using namespace std;

%}

/* 空白符和注释 */
WhiteSpace [ \t\n\r]*
LineComment "//".*
MultiLineComment "/*"([^*]|\*+[^*/])*\*+"/"

/* 标识符 */
Identifier [a-zA-Z_][a-zA-Z0-9_]*

/* 整数字面量 */
Decimal [1-9][0-9]*
Octal 0[0-7]*
Hexadecimal 0[xX][0-9a-fA-F]+

最前面的：

1
2
3


%option noyywrap
%option nounput
%option noinput

是 Flex 的一些配置选项。默认情况下，Flex 会生成一些我们当前用不到的接口，因此这里直接将它们关闭。

被：

1
2
3


%{
...
%}

包围的代码会被原样插入 Flex 生成的源文件。

这里需要包含：

1

#include "sysy.tab.hpp"

因为稍后的规则中需要使用：

1
2
3
4


INT
RETURN
IDENT
INT_CONST

等 Token，而这些 Token 的编号，以及 yylval 的类型，都是由 Bison 生成的头文件定义的。

后面的：

1

Identifier [a-zA-Z_][a-zA-Z0-9_]*

相当于给一段正则表达式起一个名字。之后在规则区中就可以直接写：

1

{Identifier}

而不需要反复写完整的正则表达式。

多行注释稍微特殊一些。在某些支持非贪婪匹配的正则表达式引擎中，可以写成类似：

1

/\*.*?\*/

但 Flex 并不直接支持这种写法，而且 . 默认不能匹配换行符，因此可以写成：

1

"/*"([^*]|\*+[^*/])*\*+"/"

其中：

1

[^*]

表示任意不是 * 的字符，因此也可以匹配换行符；而：

1

\*+[^*/]

则用于处理注释内部出现的一个或多个 *，同时避免过早将它们识别为结束标记 */。

规则区位于两个 %% 之间。每一条规则都由“模式 + 动作”组成，当 Flex 匹配到某个模式时，就执行后面的 C++ 动作：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


{WhiteSpace} { /* 忽略 */ }
{LineComment} { /* 忽略 */ }
{MultiLineComment} { /* 忽略 */ }

"int" { return INT; }
"return" { return RETURN; }

{Identifier} {
 yylval.str_val = new string(yytext);
 return IDENT;
}

{Decimal} {
 yylval.int_val = strtol(yytext, nullptr, 0);
 return INT_CONST;
}

{Octal} {
 yylval.int_val = strtol(yytext, nullptr, 0);
 return INT_CONST;
}

{Hexadecimal} {
 yylval.int_val = strtol(yytext, nullptr, 0);
 return INT_CONST;
}

. {
 return yytext[0];
}

Flex 在存在多条可以匹配的规则时，会遵循两个原则：

优先选择能够匹配最长字符串的规则；
如果匹配长度相同，则选择写在前面的规则。

例如 int 既可以匹配：

1

"int"

也可以匹配：

1

{Identifier}

两者匹配长度都是 3，因此 Flex 会选择写在前面的 "int" 规则。这也是为什么关键字通常要写在标识符规则之前。

在动作中，我们还会经常使用几个 Flex 提供的变量：

yytext：当前刚刚匹配到的源代码文本，是一个 C 风格字符串；
yyleng：当前 yytext 的长度；
yylval：传递给语法分析器的语义值。

例如输入：

1

main

被 {Identifier} 匹配后：

1

yytext

的内容就是 "main"。

而：

1

yylval.str_val = new string(yytext);

则将真正的标识符名称保存下来并传递给 Bison。

对于整数：

1

yylval.int_val = strtol(yytext, nullptr, 0);

则把文本形式的整数转换为真正的数值。

这里的：

1
2


str_val
int_val

会在稍后的 Bison %union 中定义。

最后：

1

. { return yytext[0]; }

表示，如果前面的所有规则都没有匹配，就直接把当前单个字符作为 Token 返回。

因此：

1
2
3
4
5


(
)
{
}
;

这些字符不需要分别定义 LPAREN、RPAREN 等 Token，而是可以直接返回字符本身。

最后一个 %% 之后是用户代码区。虽然目前我们暂时没有使用这一部分，但以后可以在这里定义一些普通的 C++ 辅助函数。

Bison 教程

完成词法分析器之后，接下来使用 Bison 生成语法分析器。

首先在 src 目录中创建：

1

sysy.y

与 Flex 类似，Bison 文件同样使用两个 %% 分成三个部分：

1
2
3
4
5


声明区
%%
文法区
%%
用户代码区

声明区主要负责插入 C++ 代码、声明 Token、定义语义值类型、定义非终结符的语义类型，以及给 parser 增加额外参数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


%code requires {
 #include <memory>
 #include <string>
}

%{

#include <iostream>
#include <memory>
#include <string>

int yylex();
void yyerror(std::unique_ptr<std::string> &ast, const char *s);

using namespace std;

%}

%parse-param { std::unique_ptr<std::string> &ast }

%union {
 std::string *str_val;
 int int_val;
}

%token INT RETURN
%token <str_val> IDENT
%token <int_val> INT_CONST

%type <str_val> FuncDef FuncType Block Stmt Number

其中：

1
2
3


%code requires {
 ...
}

中的代码会被放入 Bison 生成的头文件 sysy.tab.hpp 中。

而：

1
2
3


%{
...
%}

中的内容主要会进入 Bison 生成的解析器源文件。

这里：

1

int yylex();

用于声明 Flex 生成的词法分析器函数。Bison 在需要读取下一个 Token 时，就会调用 yylex()。

而：

1

void yyerror(...);

用于声明语法分析发生错误时调用的错误处理函数。

1

%parse-param { std::unique_ptr<std::string> &ast }

表示给生成的 yyparse() 增加一个额外参数。于是我们就可以：

1
2


unique_ptr<string> ast;
yyparse(ast);

解析完成之后，再把最终结果通过 ast 交回调用方。

这里暂时使用一个字符串保存语法分析的结果，在下一节中再把它真正替换成 AST。

在语法分析过程中，不同 Token 和非终结符可能携带不同类型的值。例如：

1

IDENT

需要携带一个：

1

std::string *

而：

1

INT_CONST

需要携带一个：

1

int

因此 Bison 使用：

1
2
3
4


%union {
 std::string *str_val;
 int int_val;
}

定义语义值可能采用的类型。

于是 Flex 中的：

1

yylval.str_val

和：

1

yylval.int_val

就是这里定义的两个字段。

这里暂时使用 std::string *，而不是直接使用 std::string，是因为传统 C 风格 union 对带有非平凡构造函数和析构函数的 C++ 类型处理起来比较麻烦。

接下来：

1

%token INT RETURN

声明 INT 和 RETURN 两种 Token。

而：

1
2


%token <str_val> IDENT
%token <int_val> INT_CONST

则表示 IDENT 携带 str_val 类型的语义值，INT_CONST 携带 int_val 类型的语义值。

这些 Token 名字必须与 Flex 中：

1
2
3
4


return INT;
return RETURN;
return IDENT;
return INT_CONST;

使用的名字一致。

最后：

1

%type <str_val> FuncDef FuncType Block Stmt Number

表示这些非终结符的语义值类型都是：

1

std::string *

也就是说，当这些非终结符完成规约后，会产生一个字符串结果并继续向上传递。

Bison 的文法规则基本形式如下：

1
2
3
4
5


非终结符
 : 产生式 {
 动作
 }
 ;

如果一个非终结符存在多个产生式，则可以使用 | 分隔。

目前我们需要解析的程序只有：

1
2
3


int main() {
 return 0;
}

整个程序只包含一个函数定义，因此：

1

CompUnit ::= FuncDef;

在 Bison 中可以写成：

1
2
3
4
5


CompUnit
 : FuncDef {
 ast = unique_ptr<string>($1);
 }
 ;

这里：

1

$1

表示产生式右侧第一个符号的语义值。

因为右侧只有一个 FuncDef，所以 $1 就是 FuncDef 的返回值。

当整个输入最终被成功规约为开始符号 CompUnit 时，语法分析就完成了，因此我们把 $1 保存到 ast 中作为最终结果。

接下来是：

1

FuncDef ::= FuncType IDENT "(" ")" Block;

对应：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


FuncDef
 : FuncType IDENT '(' ')' Block {
 auto type = unique_ptr<string>($1);
 auto ident = unique_ptr<string>($2);
 auto block = unique_ptr<string>($5);

 $$ = new string(
 *type + " " + *ident + "()" + *block
 );
 }
 ;

这里需要认识 Bison 中两个非常重要的记号。

$1、$2 等表示产生式右侧各个符号的语义值，例如：

1
2


FuncType IDENT '(' ')' Block
 $1 $2 $3 $4 $5

而：

1

$$

则表示当前产生式左侧非终结符的语义值。

因此：

1

$$ = new string(...);

表示这几个符号被规约成 FuncDef 后，FuncDef 自身的语义值就是这个新生成的字符串。

这里：

1
2
3


auto type = unique_ptr<string>($1);
auto ident = unique_ptr<string>($2);
auto block = unique_ptr<string>($5);

则是使用 unique_ptr 接管之前通过 new string(...) 创建的字符串。

例如 $1 原本只是一个裸指针：

1

string *

将它交给：

1

unique_ptr<string>

后，这块内存就由智能指针负责管理。当当前语义动作执行结束、局部变量离开作用域时，对应的字符串也会被自动释放，因此我们不需要手动调用 delete。

剩下的语法可以按照同样的方法实现：

1
2
3
4


FuncType ::= "int";
Block ::= "{" Stmt "}";
Stmt ::= "return" Number ";";
Number ::= INT_CONST;

对应：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


FuncType
 : INT {
 $$ = new string("int");
 }
 ;

Block
 : '{' Stmt '}' {
 auto stmt = unique_ptr<string>($2);
 $$ = new string("{" + *stmt + "}");
 }
 ;

Stmt
 : RETURN Number ';' {
 auto number = unique_ptr<string>($2);
 $$ = new string("return " + *number + ";");
 }
 ;

Number
 : INT_CONST {
 $$ = new string(to_string($1));
 }
 ;

随着 Bison 不断进行规约，这些字符串会逐层向上传递：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


INT_CONST
 │
 ▼
 Number
 │
 ▼
 Stmt
 │
 ▼
 Block
 │
 ▼
 FuncDef
 │
 ▼
CompUnit

最终可以得到类似：

1

int main(){return 0;}

这样的结果。

需要注意的是，这里还没有真正构造 AST。我们只是暂时使用字符串来模拟语法分析结果，从而熟悉 Bison 的语义动作以及 $1、$$ 等机制。真正的 AST 会在下一节实现。

第二个 %% 之后是用户代码区。目前我们只需要定义错误处理函数：

1
2
3


void yyerror(unique_ptr<string> &ast, const char *s) {
 cerr << "error: " << s << endl;
}

当 Bison 在语法分析过程中发现输入不符合文法时，就会调用 yyerror() 输出错误信息。

生成词法 / 语法分析器

完成 sysy.l 和 sysy.y 后，Flex 和 Bison 就可以根据我们的规则生成真正的词法分析器和语法分析器。

接下来修改：

1

src/main.cpp

内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


#include <cassert>
#include <cstdio>
#include <iostream>
#include <memory>
#include <string>

using namespace std;

extern FILE *yyin;
extern int yyparse(unique_ptr<string> &ast);

int main(int argc, const char *argv[]) {
 assert(argc == 5);

 auto mode = argv[1];
 auto input = argv[2];
 auto output = argv[4];

 yyin = fopen(input, "r");
 assert(yyin);

 unique_ptr<string> ast;

 auto ret = yyparse(ast);
 assert(!ret);

 cout << *ast << endl;

 return 0;
}

其中：

1

extern FILE *yyin;

表示 Flex 应该从哪个文件读取输入。

因此：

1

yyin = fopen(input, "r");

就是将需要编译的 SysY 源文件交给词法分析器。

而：

1

yyparse(ast);

会启动 Bison 生成的语法分析器。当语法分析器需要新的 Token 时，就会调用 Flex 生成的：

1

yylex()

因此整个过程可以表示为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


SysY 源文件
 │
 ▼
 Flex
 │
 │ yylex()
 ▼
 Token
 │
 ▼
 Bison
 │
 │ 规约
 ▼
解析结果

接下来进入开发环境：

1
2
3


docker run -it --rm \
 -v /path/to/compiler:/root/compiler \
 maxxing/compiler-dev bash

编译项目：

1

cmake --build build

然后运行：

1

./build/compiler --koopa debug/lab1.sy -o debug/lab1.koopa

此时可以看到输出：

1

int main(){return 0;}

这说明我们的词法分析器和语法分析器已经能够正确识别：

1
2
3


int main() {
 return 0;
}

到这里，我们已经完成了最基本的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


源代码
 │
 ▼
词法分析
 │
 ▼
Token Stream
 │
 ▼
语法分析
 │
 ▼
程序结构

不过，目前所谓的“程序结构”仍然只是通过字符串拼接得到的临时结果。

在下一节中，我们会正式定义 AST（Abstract Syntax Tree），并让 Bison 在语法分析过程中直接构造真正的 AST。

解析 main 函数：构建 AST

在第一节中，我们借助 Flex 和 Bison 实现了一个能够解析简单 main 函数的编译器前端。

不过，此时语法分析器只是将解析结果重新拼接成一个字符串。虽然这足以帮助我们理解 Bison 的基本工作方式，但字符串并不适合作为后续编译阶段处理程序的数据结构。

因此，在本节中，我们将正式设计 AST，并让 Bison 在语法分析过程中直接构造 AST。

设计 AST

AST，即 Abstract Syntax Tree（抽象语法树），用于保存源程序中对后续编译阶段真正有意义的结构。

后续的语义分析、中间代码生成以及优化，都需要在 AST 上进行，因此 AST 的设计主要需要考虑两点：

能够表达程序中必要的语法和语义结构；
尽可能方便后续编译阶段处理。

在当前实验中，我们处理的语法如下：

1
2
3
4
5
6
7
8


CompUnit ::= FuncDef;

FuncDef ::= FuncType IDENT "(" ")" Block;
FuncType ::= "int";

Block ::= "{" Stmt "}";
Stmt ::= "return" Number ";";
Number ::= INT_CONST;

从文法结构来看，可以得到大致如下的层次关系：

1
2
3
4
5
6
7


CompUnit
└── FuncDef
 ├── FuncType
 ├── IDENT
 └── Block
 └── Stmt
 └── Number

因此，可以先按照这个结构设计 AST。

首先创建：

1

src/ast.hpp

并定义所有 AST 节点的公共基类：

1
2
3
4
5
6
7
8
9


#pragma once

#include <memory>
#include <string>

class BaseAST {
public:
 virtual ~BaseAST() = default;
};

这里：

1

#pragma once

用于避免同一个头文件在一个编译单元中被重复包含，从而防止类或函数被重复定义。

而：

1

virtual ~BaseAST() = default;

则定义了一个虚析构函数。

之后，我们会经常使用：

1

std::unique_ptr<BaseAST>

来保存不同类型的 AST 节点。例如：

1
2


std::unique_ptr<BaseAST> ast =
 std::make_unique<FuncDefAST>();

虽然指针类型是 BaseAST，但实际对象可能是 FuncDefAST、BlockAST 等派生类。因此，基类的析构函数必须是虚函数，这样通过 BaseAST 指针销毁对象时，才能正确调用实际派生类的析构函数。

接下来可以根据文法定义具体的 AST 节点。

例如：

1

CompUnit ::= FuncDef;

说明一个 CompUnit 中包含一个 FuncDef，因此可以写成：

1
2
3
4


class CompUnitAST : public BaseAST {
public:
 std::unique_ptr<BaseAST> func_def;
};

类似地：

1

FuncDef ::= FuncType IDENT "(" ")" Block;

可以对应：

1
2
3
4
5
6


class FuncDefAST : public BaseAST {
public:
 std::unique_ptr<BaseAST> func_type;
 std::string ident;
 std::unique_ptr<BaseAST> block;
};

这里需要注意，文法中的每个符号并不一定都要在 AST 中单独建立节点。

例如：

1
2
3
4
5


(
)
{
}
;

这些符号只是用来约束源代码的语法形式，一旦语法分析完成，它们就没有必要继续保留。

类似地：

1
2


int
return

通常也不需要作为独立节点保存。因为一旦我们已经构造了 FuncTypeAST 或 ReturnStmtAST，节点类型本身就已经表达了对应的语义。

而：

1
2


IDENT
INT_CONST

则不同。

例如：

1
2
3


int main() {
 return 123;
}

其中：

1
2


main
123

都是程序本身携带的数据，因此必须在 AST 中保存，例如：

1
2


std::string ident;
int value;

所以

是否需要建立节点或者保存字段，取决于这部分信息对后续编译阶段是否仍然有意义。

这也是 AST 与普通语法树的一个重要区别。

如果严格按照 EBNF 的每一层都建立节点，那么得到的结构更接近 CST（Concrete Syntax Tree，具体语法树）。

而 AST 会主动省略很多只服务于语法分析的细节。

例如：

1

Stmt ::= "return" Number ";";

理论上完全可以直接设计成：

1
2
3
4


class ReturnStmtAST : public BaseAST {
public:
 int value;
};

而不一定非要保留：

1
2


StmtAST
└── NumberAST

不过在当前实验中，为了更直观地理解 Bison 如何逐层构造 AST，我们暂时让 AST 的结构和 EBNF 保持得比较接近。

生成 AST

设计好 AST 之后，就可以在 Bison 的语法动作中真正构造这些节点了。

在上一节中，我们对每个语法单元的处理方式都是：

1

std::string *

每完成一次规约，就把对应的内容重新拼成字符串。

现在我们要把它替换成：

1

BaseAST *

也就是说：

Bison 每完成一次规约，就构造一个对应的 AST 节点，并将这个节点继续向上传递。

首先修改 src/sysy.y。

我们需要让 Bison 生成的头文件能够看到 BaseAST 的定义，因此：

1
2
3
4
5


%code requires {
 #include <memory>
 #include <string>
 #include "ast.hpp"
}

这里使用的是：

1

%code requires

而不是单纯的：

1
2
3


%{
...
%}

原因是 Bison 不仅会生成：

1

sysy.tab.cpp

还会生成：

1

sysy.tab.hpp

而 %union 等声明可能需要出现在生成的头文件中。

因为这些声明中会使用：

1

BaseAST *

所以 ast.hpp 也必须在生成的头文件中可见。

接下来，将 parser 的额外参数从：

1

%parse-param { std::unique_ptr<std::string> &ast }

修改为：

1

%parse-param { std::unique_ptr<BaseAST> &ast }

这样，语法分析完成以后，得到的根节点就可以通过：

1

std::unique_ptr<BaseAST> ast;

传回 main 函数。

接下来修改 %union：

1
2
3
4
5


%union {
 std::string *str_val;
 int int_val;
 BaseAST *ast_val;
}

在上一节中，非终结符的语义值都是：

1

std::string *

现在则改成 AST 节点指针：

1

%type <ast_val> FuncDef FuncType Block Stmt Number

这样，像 FuncDef、Block 这样的非终结符在完成规约以后，返回的就是一个 AST 节点。

首先来看：

1

CompUnit ::= FuncDef;

对应的 Bison 代码可以写成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


CompUnit
 : FuncDef {
 auto comp_unit = std::make_unique<CompUnitAST>();

 comp_unit->func_def =
 std::unique_ptr<BaseAST>($1);

 ast = std::move(comp_unit);
 }
 ;

这里：

1

$1

表示产生式右侧第一个符号，也就是 FuncDef 的语义值。

因为：

1

%type <ast_val> FuncDef

所以 $1 的实际类型就是：

1

BaseAST *

接下来：

1

std::unique_ptr<BaseAST>($1)

将这个裸指针交给 unique_ptr 管理。

最后：

1

ast = std::move(comp_unit);

把当前构造出的 CompUnitAST 交给 parser 的输出参数 ast。

这里涉及 unique_ptr 的所有权转移。

例如：

1

auto comp_unit = std::make_unique<CompUnitAST>();

此时 AST 对象由：

1

comp_unit

独占管理。

而 unique_ptr 不能被复制，因此不能直接：

1

ast = comp_unit;

而需要：

1

ast = std::move(comp_unit);

表示：

1
2
3
4
5


comp_unit
 │
 │ 所有权转移
 ▼
 ast

执行之后，AST 对象由 ast 管理，而原来的 comp_unit 会变成空指针。

因此，这里的 std::move 并不是把 AST 对象本身“搬走”，而是把：

对这个 AST 对象的所有权从一个 unique_ptr 转移给另一个 unique_ptr。

接下来处理：

1

FuncDef ::= FuncType IDENT "(" ")" Block;

可以写成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


FuncDef
 : FuncType IDENT '(' ')' Block {
 auto ast = new FuncDefAST();

 ast->func_type =
 std::unique_ptr<BaseAST>($1);

 ast->ident =
 *std::unique_ptr<std::string>($2);

 ast->block =
 std::unique_ptr<BaseAST>($5);

 $$ = ast;
 }
 ;

这里：

分别表示：

1
2


FuncType IDENT '(' ')' Block
 $1 $2 $3 $4 $5

而：

1

$$

表示产生式左侧 FuncDef 的语义值。

因此：

1

$$ = ast;

表示：

当前这些符号规约成 FuncDef 后，FuncDef 对应的 AST 节点就是刚刚构造出的 FuncDefAST。

整个过程可以理解成：

1
2
3
4
5


FuncType IDENT '(' ')' Block
 │
 │ 规约
 ▼
 FuncDefAST

然后这个节点会继续作为 $1、$2 等语义值被更上层的规则使用。

对于：

1

FuncType ::= "int";

可以写成：

1
2
3
4
5
6


FuncType
 : INT {
 auto ast = new FuncTypeAST();
 $$ = ast;
 }
 ;

因为当前只支持 int 一种函数返回类型，所以 FuncTypeAST 暂时不需要保存额外的数据。

以后如果支持：

1
2
3


int
void
float

等不同类型，再在 FuncTypeAST 中添加对应字段即可。

其他规则也可以按照完全相同的方法构造 AST。

整个过程本质上就是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


Token
 │
 ▼
Bison 规约
 │
 ├── NumberAST
 │
 ▼
StmtAST
 │
 ▼
BlockAST
 │
 ▼
FuncDefAST
 │
 ▼
CompUnitAST

随着语法分析不断进行，较小的 AST 节点被逐步组合成较大的 AST 节点，最终形成整棵树。

parser 参数改变以后，yyerror 也需要同步修改：

1
2
3
4
5


void yyerror(
 std::unique_ptr<BaseAST> &ast,
 const char *s) {
 ...
}

同时，main.cpp 中原来的：

1

extern int yyparse(unique_ptr<string> &ast);

也需要改成：

1

extern int yyparse(unique_ptr<BaseAST> &ast);

这样，语法分析器最终返回的就不再是一个字符串，而是一棵真正的 AST。

检查生成结果

现在 AST 已经可以正确构造出来了，但它暂时只保存在内存中。

为了检查生成结果是否符合我们的预期，我们希望能够把整棵 AST 打印到终端。

可以利用 C++ 的虚函数机制，在 BaseAST 中增加一个统一的：

1

Dump()

接口：

1
2
3
4
5
6


class BaseAST {
public:
 virtual ~BaseAST() = default;

 virtual void Dump() const = 0;
};

这里：

1

= 0

表示 Dump() 是一个纯虚函数。

因此，BaseAST 本身不能直接实例化，而所有具体的 AST 节点都需要实现自己的 Dump()。

例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


class CompUnitAST : public BaseAST {
public:
 std::unique_ptr<BaseAST> func_def;

 void Dump() const override {
 std::cout << "CompUnitAST { ";
 func_def->Dump();
 std::cout << " }";
 }
};

类似地：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


class FuncDefAST : public BaseAST {
public:
 std::unique_ptr<BaseAST> func_type;
 std::string ident;
 std::unique_ptr<BaseAST> block;

 void Dump() const override {
 std::cout << "FuncDefAST { ";

 func_type->Dump();

 std::cout << ", "
 << ident
 << ", ";

 block->Dump();

 std::cout << " }";
 }
};

虽然：

1
2
3


func_def
func_type
block

这些字段的静态类型都是：

1

std::unique_ptr<BaseAST>

但它们实际指向的对象可能分别是：

1
2
3


FuncDefAST
FuncTypeAST
BlockAST

由于 Dump() 是虚函数，所以调用：

1

func_def->Dump();

时，C++ 会根据对象的实际类型自动调用正确的 Dump() 实现。

这就是 C++ 中的运行时多态。

最后，在 main.cpp 中：

1
2
3
4
5
6
7


std::unique_ptr<BaseAST> ast;

auto ret = yyparse(ast);
assert(!ret);

ast->Dump();
std::cout << std::endl;

对于输入：

1
2
3


int main() {
 return 0;
}

最终可以得到类似：

1
2
3
4
5
6
7
8
9


CompUnitAST {
 FuncDefAST {
 FuncTypeAST { int },
 main,
 BlockAST {
 StmtAST { 0 }
 }
 }
}

这样的输出。

整个编译前端到这里已经形成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


源代码
 │
 ▼
Flex
 │
 ▼
Token Stream
 │
 ▼
Bison
 │
 ▼
AST

相比上一节单纯把内容重新拼接成字符串，现在的语法分析器已经真正把源程序转换成了一种结构化表示。

换句话说，之前我们主要是在判断：

1

这个程序是否符合语法？

而现在，在确认程序符合语法的同时，我们还得到了：

1

这个程序的结构是什么？

这棵 AST 也将成为后续生成 Koopa IR 的基础。

IR生成

在上一节中，我们已经成功让编译器能够将简单的 SysY 程序解析为 AST。在此基础上，就可以继续进行后续的编译工作，例如生成中间表示（IR）。

在实际的编译器实现中，通常没有必要从头实现完整的后端。借助 LLVM IR 等成熟的编译基础设施，我们可以将源程序转换为统一的中间表示，再把后续的优化、指令选择、寄存器分配以及机器码生成等工作交给现有工具链完成。

因此，本小节将继续完善我们的编译器，实现从 AST 到 IR 的转换。

Koopa IR 基础

在 Koopa IR 中，最大的结构单位是 Program，它代表一个完整的 Koopa IR 程序。

一个 Program 由若干全局值（Value）和函数（Function）组成。其中，每个 Function 又由若干基本块（BasicBlock）构成，而基本块中则包含一系列指令。需要注意的是，在 Koopa IR 中，指令本身也是一种 Value。

因此，一个 Koopa IR 程序的基本结构如下：

1
2
3
4
5
6
7
8


Program
├── Global Values
│
└── Functions
 └── Function
 └── BasicBlocks
 └── BasicBlock
 └── Values / Instructions

接下来，我们重点介绍其中涉及到的几个基本概念。

首先是基本块（Basic Block）。基本块可以理解为一系列连续执行的指令，它具有以下特点：

只有一个入口点：如果其他基本块要将控制流转移到当前基本块，只能跳转到基本块的开头，而不能直接跳到基本块中间的某条指令。
控制流只能在末尾发生转移：基本块中只有最后一条指令可以改变控制流，例如跳转到其他基本块，或者从当前函数中返回（执行 return）。

基本块的存在能够简化编译过程中大量与控制流相关的分析，因此 Koopa IR 要求函数中的指令按照基本块进行组织。

同时，Koopa IR 约定函数的第一个基本块为函数的入口基本块。也就是说，当函数开始执行时，会首先从第一个基本块开始执行。

在本次实验中，我们暂时不需要考虑全局变量。同时，也可以暂时认为 Program 的函数列表中只有一个 Function，而这个 Function 中又只有一个 BasicBlock，也就是函数的入口基本块。

基本块中包含的指令同样属于 Value。Koopa IR 中主要包含以下几类 Value（更详细的介绍可以参考：文档）：

各类常量：整数常量（Integer）、零初始化器（ZeroInit）等。
参数引用：例如函数参数引用（FuncArgRef），用于表示传入函数的参数。
内存分配：全局内存分配（GlobalAlloc，全局变量通过它表示）和局部内存分配（Alloc）。
访存指令：加载（Load）和存储（Store）。
指针运算：GetPtr 和 GetElemPtr。
二元运算：Binary，例如加、减、乘、除、取模以及各种比较运算。
控制流转移：条件分支（Branch）和无条件跳转（Jump）。
函数相关操作：函数调用（Call）和函数返回（Return）。

在本节实验中，我们实际会用到的只有两种：整数常量 Integer 和函数返回 Return。

至此，我们需要生成的 Koopa IR 就已经非常明确了：

生成一个 Koopa IR Program。
Program 中包含一个名为 main 的函数。
函数中包含一个基本块。
基本块中包含一条返回指令。
返回指令的返回值，就是 SysY 中 return 语句后面的整数常量。

如果手动编写对应的 Koopa IR，它大致如下：

1
2
3
4


fun @main(): i32 {
%entry:
 ret 0
}

这里还有几个需要注意的地方：

符号名称的规范。可以看到，这里的函数名是 @main，而不是之前 SysY 程序中的 main。这是因为 Koopa IR 规定，Function、BasicBlock 和具名 Value 的名字必须以 @ 或 % 开头。@ 和 % 在语义上并没有本质区别，但在使用习惯上，我们通常使用 @ 表示源程序中本身就存在的符号，例如函数名和全局变量名；而使用 % 表示编译器在生成 IR 的过程中产生的局部符号或临时值。因此：@main对应的是 SysY 程序中的 main.而：%entry则是我们在生成 IR 时人为创建的基本块名称。
Koopa IR 是一种强类型 IR。也就是说，函数参数、函数返回值以及各种 Value 都具有明确的类型。例如：fun @main(): i32中的 i32 表示 main 函数的返回值类型为 32 位整数，对应 SysY 中的 int。不过，我们并不需要在文本形式的 Koopa IR 中为每一个值都显式写出类型。很多情况下，Koopa IR 的解析器可以根据上下文推导出对应的类型，因此可以省略一部分类型标注。例如：ret 0中并没有显式写出 0 的类型，但根据当前函数的返回类型以及 ret 指令的语义，可以确定这里返回的是一个 i32 整数。
基本块的名字可以自行指定。基本块叫什么并不会影响程序语义，例如 %entry、%start 等都可以使用。不过，给基本块起一个具有实际含义的名字，通常能够让生成的 IR 更容易阅读，也更方便我们在后续调试编译器时定位问题。

生成 Koopa IR（1）——Koopa IR 数据结构

生成 Koopa IR 最直接的方式，其实和我们之前在命令行中输出 AST 很类似：给不同的 AST 节点实现对应的输出逻辑，然后遍历 AST，直接输出 Koopa IR 文本即可。

不过在正式实现之前，我们先区分 Koopa IR 的两种表示形式：

文本形式：也就是字符串形式，主要方便人阅读、调试以及在不同工具之间传递。
内存形式：也就是使用程序中的数据结构来表示 IR，方便编译器对其进行遍历、分析和修改。

我们的编译器最终需要输出文本形式的 Koopa IR。之后，这些文本 IR 可以被 koopac 等 Koopa IR 工具读取并解析为内存形式，以进行进一步处理。Koopa IR 框架本身也提供了相关接口，用于处理不同形式的 IR。

因此，考虑到上述情况，我们主要有两种实现思路：

遍历 AST，直接输出文本形式的 IR。这种方式最简单，也适用于使用任意语言实现的编译器。
像定义 AST 一样，定义一套表示 Koopa IR 的数据结构，例如指令、基本块和函数等。首先遍历 AST 生成这些 IR 数据结构，然后再遍历 IR，将其输出为字符串。

虽然第一种方案最简单，但从工程结构上看，它实际上把两个不同的过程：

1
2


AST -> IR
IR -> Text

杂糅在了一起，不利于后续扩展和维护。

因此，我们选择第二种方案。此时整个流程变成：

1
2
3
4
5
6
7
8
9


AST
 ↓
IR Generation
 ↓
Koopa IR 内存结构
 ↓
IR Printer
 ↓
Koopa IR 文本

也就是说，AST 不负责输出 Koopa IR 字符串，IR 数据结构也不需要理解 AST，二者之间通过 IR Generation，也就是 AST 到 IR 的转换过程连接起来。

目前，我们并不需要一开始就实现完整的 Koopa IR 数据结构。根据本次实验的要求，我们只需要支持如下结构：

1
2
3
4
5
6
7


Program
└── Function
 └── BasicBlock
 └── Value
 ├── Integer
 └── Instruction
 └── Return

下面我们来具体设计 Koopa IR 的数据结构。

根据 Koopa IR 的设计，一个完整的程序由若干 Function 和全局 Value 组成，而每个 Function 又由若干 BasicBlock 组成，BasicBlock 中包含一系列指令。

与此同时，指令本身也属于 Value 的一种。因此，Value 可以看作 Koopa IR 中最基础的抽象之一。

我们首先使用枚举表示不同种类的 Value。同时，为了表示 IR 中的数据类型，再额外定义 IRType：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


enum class ValueKind
{
 Integer,
 Return
};

enum class IRType
{
 I32,
};

其中需要注意：

ValueKind 表示当前 IR 节点“是什么”，例如整数常量还是 Return 指令。
IRType 表示数据本身的类型，例如这里的 I32。

有了 ValueKind 后，我们就可以定义所有 IR Value 的基类 IRValue：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


class IRValue
{
public:
 const ValueKind kind;
 virtual ~IRValue() = default;

protected:
 explicit IRValue(ValueKind kind)
 : kind(kind) {}
};

kind 用来记录当前 IRValue 的具体种类，而构造函数被声明为 protected，因为我们并不会直接创建一个普通的 IRValue，而是通过其派生类创建具体的 IR 节点。

在此基础上，可以进一步派生出当前实验需要的两类 Value：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


class IRInteger : public IRValue
{
public:
 int value;

 explicit IRInteger(int value)
 : IRValue(ValueKind::Integer),
 value(value) {}
};

class Instruction : public IRValue
{
protected:
 explicit Instruction(ValueKind kind)
 : IRValue(kind) {}
};

其中，IRInteger 表示整数常量，而 Instruction 表示所有指令的公共基类。

这里体现了一个很重要的关系：

1
2
3


IRValue
├── IRInteger
└── Instruction

也就是说，所有指令都是 Value，但并不是所有 Value 都是指令。例如整数常量 IRInteger 是一个 Value，但它并不是一条指令。

而 Instruction 又可以进一步派生出具体的指令类型。例如本次实验中需要使用的 Return：

1
2
3
4
5
6
7
8
9


class Return : public Instruction
{
public:
 std::unique_ptr<IRValue> operand;

 explicit Return(std::unique_ptr<IRValue> operand)
 : Instruction(ValueKind::Return),
 operand(std::move(operand)) {}
};

这里的 operand 表示 Return 指令的返回值。

例如：

1

return 42;

对应的 IR 数据结构可以理解为：

1
2


Return
└── IRInteger(42)

需要注意的是，我们并没有把 operand 定义在 Instruction 基类中，而是让具体的指令自行维护自己的操作数。

这是因为不同指令拥有的操作数数量和含义并不相同。例如 Return 只有一个返回值，而后续的二元运算指令通常会有两个操作数。因此，把操作数交给具体指令管理会更加合理。

有了这些最基础的 IR 节点后，我们就可以进一步向上组织它们。

首先，多条指令共同组成一个 BasicBlock：

1
2
3
4
5
6
7
8
9


class BasicBlock
{
public:
 std::string name;
 std::vector<std::unique_ptr<Instruction>> insts;

 explicit BasicBlock(std::string name)
 : name(std::move(name)) {}
};

这里需要注意，BasicBlock 中保存的是：

1

std::vector<std::unique_ptr<Instruction>>

而不是所有 IRValue。

这是因为基本块本质上包含的是一系列需要依次执行的指令。虽然 Instruction 同时也是一种 IRValue，但像 IRInteger 这样的常量并不会单独作为一条指令出现在基本块的指令列表中。

若干个 BasicBlock 又共同组成一个 Function：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


class Function
{
public:
 std::string name;
 IRType ret_type;
 std::vector<std::unique_ptr<BasicBlock>> bbs;

 Function(std::string name, IRType ret_type)
 : name(std::move(name)),
 ret_type(ret_type) {}
};

其中：

name 表示函数名称；
ret_type 表示函数返回值类型；
bbs 保存函数中的所有基本块。

最后，若干个 Function 组成整个 Program：

1
2
3
4
5


class Program
{
public:
 std::vector<std::unique_ptr<Function>> funcs;
};

完整的 Koopa IR Program 实际上还可以包含全局 Value，不过在当前 Lv1 实验中并不会使用到，因此这里暂时只保存函数。

至此，我们就完成了当前实验所需要的 Koopa IR 数据结构设计：

1
2
3
4
5
6


Program
└── Function
 └── BasicBlock
 └── Instruction
 └── Return
 └── IRInteger

有了这套内存中的 IR 表示后，接下来就可以完成两件事情：

1
2
3
4
5
6
7


AST
 ↓
生成 Koopa IR 数据结构
 ↓
IR Printer
 ↓
Koopa IR 文本

也就是说，下一步真正需要实现的，就是 AST 到 Koopa IR 的转换。

生成 Koopa IR（2）——Koopa IR 转换与打印

从 AST 到 Koopa IR 的转换并不复杂，在实现思路上，我们完全可以参考之前输出 AST 时使用的 Dump：从根节点开始，递归遍历整棵 AST，并根据不同类型的 AST 节点生成对应的 IR 节点。

不过，为了保持上一节中确定的设计，我们并不会直接在 AST 中实现 IR 生成逻辑，而是单独设计一个 IRGenerator，负责：

1

AST -> Koopa IR

同时，再使用 IRPrinter 负责：

1

Koopa IR -> Text

这样做虽然相比直接在 AST 中添加一个 DumpIR 方法多了一层结构，但也带来了一个明显的好处：

如果我们想了解 AST 是如何转换成 IR 的，直接查看 IRGenerator 即可；
如果我们想了解 IR 是如何被打印成 Koopa IR 文本的，直接查看 IRPrinter 即可。

这样就不需要在 AST 的各种节点中频繁切换上下文，也使不同模块之间的职责更加清晰。

整个过程可以表示为：

1
2
3
4
5
6
7
8
9


AST
 ↓
IRGenerator
 ↓
Koopa IR 内存结构
 ↓
IRPrinter
 ↓
Koopa IR 文本

我们先来看AST 到 Koopa IR 的转换。实现上，我们可以单独创建：

1
2


src/ir_generator.hpp
src/ir_generator.cpp

然后采用类似 Dump 的递归思路，根据不同的 AST 节点生成对应的 Koopa IR 数据结构。

首先，从最外层的 CompUnitAST 开始：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Program IRGenerator::Generate(const CompUnitAST& ast) const
{
 Program program;

 const auto& func =
 static_cast<const FuncDefAST&>(*ast.func_def);

 program.funcs.push_back(GenerateFunction(func));

 return program;
}

当前实验中，一个 CompUnitAST 中只包含一个函数定义，因此我们取出其中的 FuncDefAST，生成对应的 Function，并加入 Program 中。

接下来处理函数定义：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


std::unique_ptr<Function>
IRGenerator::GenerateFunction(const FuncDefAST& ast) const
{
 auto func =
 std::make_unique<Function>(ast.ident, IRType::I32);

 auto entry =
 std::make_unique<BasicBlock>("entry");

 const auto& block =
 static_cast<const BlockAST&>(*ast.block);

 EmitBlock(block, *entry);

 func->bbs.push_back(std::move(entry));

 return func;
}

在当前实验中，函数返回类型一定是 int，因此可以直接将其转换为 Koopa IR 中的 I32。

与此同时，我们为函数创建一个名为 entry 的入口基本块，然后将函数体中的语句转换成对应的指令，并插入这个基本块。

对于 BlockAST：

1
2
3
4
5
6
7
8
9


void IRGenerator::EmitBlock(
 const BlockAST& ast,
 BasicBlock& bb) const
{
 const auto& stmt =
 static_cast<const StmtAST&>(*ast.stmt);

 EmitStmt(stmt, bb);
}

当前实验中，一个 Block 中只有一条 Stmt，因此继续递归处理即可。

接下来处理 StmtAST：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


void IRGenerator::EmitStmt(
 const StmtAST& ast,
 BasicBlock& bb) const
{
 const auto& number =
 static_cast<const NumberAST&>(*ast.number);

 bb.insts.push_back(
 std::make_unique<Return>(
 GenerateNumber(number)
 )
 );
}

当前语法中的 Stmt 只有：

1

return Number;

因此，我们首先将 NumberAST 转换成一个 IRInteger，然后将其作为操作数构造 Return 指令，最后把这条指令加入当前基本块。

最后是最底层的 NumberAST：

1
2
3
4
5


std::unique_ptr<IRValue>
IRGenerator::GenerateNumber(const NumberAST& ast) const
{
 return std::make_unique<IRInteger>(ast.value);
}

这样，一个类似：

1
2
3


int main() {
 return 0;
}

的 AST：

1
2
3
4
5
6


CompUnitAST
└── FuncDefAST
 ├── main
 └── BlockAST
 └── StmtAST
 └── NumberAST(0)

经过 IRGenerator 后，就会得到：

1
2
3
4
5


Program
└── Function("main")
 └── BasicBlock("entry")
 └── Return
 └── IRInteger(0)

这就完成了：

1

AST -> Koopa IR

的转换。

接着我们看Koopa IR 的打印。有了内存形式的 Koopa IR 后，接下来只需要按照 Koopa IR 的文本格式，将这些数据结构依次输出即可。

其过程同样是从 Program 开始递归向下遍历：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


std::string IRPrinter::Print(const Program& program) const
{
 std::string result;

 for (const auto& func : program.funcs)
 {
 result += PrintFunction(*func);
 }

 return result;
}

然后打印 Function：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


std::string
IRPrinter::PrintFunction(const Function& func) const
{
 std::string result;

 result += "fun @" + func.name + "(): ";

 if (func.ret_type == IRType::I32)
 {
 result += "i32";
 }

 result += " {\n";

 for (const auto& bb : func.bbs)
 {
 result += PrintBasicBlock(*bb);
 }

 result += "}\n";

 return result;
}

再依次打印函数中的基本块：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


std::string
IRPrinter::PrintBasicBlock(const BasicBlock& bb) const
{
 std::string result;

 result += "%" + bb.name + ":\n";

 for (const auto& inst : bb.insts)
 {
 result += " ";
 result += PrintInstruction(*inst);
 result += "\n";
 }

 return result;
}

对于具体指令，我们根据 ValueKind 判断指令类型：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


std::string
IRPrinter::PrintInstruction(const Instruction& inst) const
{
 switch (inst.kind)
 {
 case ValueKind::Return:
 {
 const auto& ret =
 static_cast<const Return&>(inst);

 return "ret " + PrintOperand(*ret.operand);
 }

 default:
 throw std::logic_error("invalid instruction kind");
 }
}

这里虽然传入的是 Instruction&，但在判断出它的 kind 为 Return 后，我们就知道这个对象实际是一个 Return，因此可以通过 static_cast 将其转换为具体的 Return 类型，从而访问其中的 operand。

同样，对于操作数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


std::string
IRPrinter::PrintOperand(const IRValue& value) const
{
 switch (value.kind)
 {
 case ValueKind::Integer:
 {
 const auto& integer =
 static_cast<const IRInteger&>(value);

 return std::to_string(integer.value);
 }

 default:
 throw std::logic_error("invalid operand kind");
 }
}

如果这个 IRValue 的类型为 Integer，那么它实际对应的是 IRInteger，因此将其转换成 IRInteger 后即可取得其中保存的整数值。

至此，我们就完成了：

1
2
3
4
5


Koopa IR 内存结构
 ↓
IRPrinter
 ↓
Koopa IR 文本

这一过程。

最后我们来看如何在主程序中使用。实现完 IRGenerator 和 IRPrinter 后，最后只需要在 main 中将它们串联起来：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


IRGenerator generator;
auto program =
 generator.Generate(
 static_cast<const CompUnitAST&>(*ast)
 );

IRPrinter printer;
auto koopa = printer.Print(program);

std::ofstream koopa_file(output);
assert(koopa_file);

koopa_file << koopa;

这样，我们完整的编译流程就变成了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


SysY 源代码
 ↓
词法分析 / 语法分析
 ↓
AST
 ↓
IRGenerator
 ↓
Koopa IR 内存结构
 ↓
IRPrinter
 ↓
Koopa IR 文本

对于：

1
2
3


int main() {
 return 0;
}

最终就可以生成：

1
2
3
4


fun @main(): i32 {
%entry:
 ret 0
}

至此，我们就完成了从 SysY AST 到 Koopa IR 的第一次完整转换。

至此，Exp Chapter 1的实验就全部完成了！我们成功的将一个简单的带有main函数的SysY代码编译为了Koopa IR程序！

[从零开始的编译原理][理论] Chapter 1：词法分析

Mon, 28 Sep 2026 20:15:14 +0800

这一章我们学习的是词法分析。

我们知道编译器通常由以下几个部分组成:

前端: 通过词法分析和语法分析，将源代码解析为抽象语法树（AST）。通过语义分析，扫描抽象语法树，检查其是否存在语义错误
中端：将AST转化为中间表示IR，并在此基础上完成一些机器无关优化
后端：将中间表示IR转换为目标平台的汇编代码，并在此基础上完成一些机器相关优化

词法分析

词法分析简单来说就是把字节流转换为单词流 (token stream). 词法分析器(lexer)会按照某种规则读文件，并将文件的内容拆分成一个个 token 作为输出, 传递给语法分析器 (parser). 同时, lexer 还会忽略文件里的一些无意义的内容, 比如空格, 换行符和注释.

Lexer 生成的 token 会包含一些信息, 用来让 parser 区分 token 的种类, 以及在必要时获取 token 的内容.

例如我们有这样一个程序:

1
2
3
4
5


int main() 
{
// 我是注释诶嘿嘿
return 0;
}

那么Lexer可能会将他转化为如下token 流:

1
2
3
4
5
6
7
8
9


种类: 关键字, 内容: int.
种类: 标识符, 内容: main.
种类: 其他字符, 内容: (.
种类: 其他字符, 内容: ).
种类: 其他字符, 内容: {.
种类: 关键字, 内容: return.
种类: 整数字面量, 内容: 0.
种类: 其他字符, 内容: ;.
种类: 其他字符, 内容: }.

目前为止，我们实现词法分析从易到难有三种方法：

词法分析器生成器
手写词法分析器
自动化词法分析器

接下来我们重点看看前面两项

词法分析器生成器

在本课程中，我们使用的词法分析生成器是antlr。

在使用antlr时，我们的输入是一个包含词法单元规约的g4文件，那么antlr会自动生成一个词法分析器

如果我们使用antlr这样的语法分析器生成器，我们主要做的事情就是就是写清楚语法规则。

我们接下来尝试用antlr实现一个类似C++的词法分析器:

首先我们知道一个C++程序肯定是由若干条Statement组成的，那么我们就有第一条语法规则：

1
2
3


grammer SimpleSysY; // 注意在g4中第一行需要定义grammer，并且保持和文件名一致

prog: stat* EOF; //这里加入EOF来说明结束条件

而statement都是由表达式expr组成的，为了简便，我们先初步规定expr只支持赋值语句和输出，那么我们可以有下一条规则:

1
2
3
4


stat: expr ';' // 需要注意''内的分号说明一条statement要以分号结尾
 | ID '=' expr ';'
 | 'print' expr ';'
 ;

接下来我们就可以去描述一个表达式的语法规则了。那么显然，这是一个递归的描述:

1
2
3
4


expr: expr ('+' | '-' | '*' | '/' ) expr
 | '(' expr ')'
 | ID
 ;

但是这样写会有点问题，这里会涉及到符号优先级的问题，例如乘法和除法的优先级肯定是高于加法和减法的，想要在antlr中表达优先级我们可以:

1
2
3
4
5


expr: expr ('*' | '/' ) expr
 | expr ('+' | '-' ) expr
 | '(' expr ')'
 | ID
 ;

当然除了优先级以外，我们还要考虑结合性的影响，在g4中，如果我们不显式指定是左结合还是右结合，就会默认是左结合，这和我们的计算是符合的，但是我们后续还会继续探讨这部分的内容。

整体上来看，语法结果就是这样，接下来我们看看词法结构:

我们知道在C++中一个标识符是以下划线或字母开头，以字母数字下划线结尾的字符串:

1

ID: ('_' | [a-zA-Z])('_' | [a-zA-Z0-9])*;

而如果此时我们用上面的写好的语法规则和词法规则去对一个语句去做测试: a = b + c;

会发现有部分的报错，这是因为空格没有被识别到，因此我们还需要加入空格的词法规则:

1

WS: [ \t\r\n]+ -> skip;

其中我们用+是因为至少要有一个才能被识别，而后面的skip则是识别到了就跳过，否则我们实际上grammar中没有相关的规则，会导致语法规则识别不出来。

这样，上面那个语句我们就可以画出语法分析树了:

当然在我们实际的实验中，这样简单的语法规则和词法规则肯定是不够的，具体的我们可以在Lab中实现，这里只做简单的介绍。

另外这里可以补充一点写语法规则和词法规则时一些需要注意的点:

特殊的规则尽量写在前面，比如docs comment和mul comment的匹配规则分别写作:

1
2


DOCS_COMMENT : '/**' .*? '*/';
MUL_COMMENT : '/*' .*? '*/'; // 其中 .*?中的？表示非贪婪匹配模式

那么此时明显可以看到DOCS_COMMENT也可以被MUL_COMMENT给匹配到的，因此我们在写词法规则的时候应该把DOCS_COMMENT的规则写在MUL_COMMENT前面，让前者优先匹配。

在antler这类词法分析器生成器中，提供了fragment的功能来进行助记:

1
2
3
4


fragment LETTER: [a-zA-Z]
fragment NUMBER: [0-9]
fragment WORD: '_' | LETTER | NUMBER
ID: ('_' | LETTER)(WORD)*;

antlr中有三个比较重要的优先匹配规则来解决冲突，分别是最前优先匹配，最长优先匹配(例如1.23会被匹配为float而不是INT和FLOAT，>=不会被识别为>和=)，非贪婪匹配

词法分析生成器的基本原理（1）

在Antlr这类词法分析器生成器中，我们只需要在g4文件中描述词法单元的正则表达式就能自动生成词法分析器，这背后的流程可以分为若干个步骤。

比较经典的流程是:

Regix->NFA->DFA->Transition Table->Machine Code

接下来我们会逐一介绍上面的各个部分

正则表达式

首先我们给出正则表达式的定义:

给定字母表$\Sigma$，$\Sigma$上的正则表达式有且仅有以下规则定义:

$\epsilon$是正则表达式
$\forall a \in \Sigma $,a是正则表达式
如果r是正则表达式，则(r)也是正则表达式
如果r与s都是正则表达式，则 r|s,rs,r*也是正则表达式

此外，我们规定正则表达式中的运算优先级如下:

$$ () > * > connect > | $$

对应的正则语言如下:

我们规定每个正则表达式r对应一个正则语言L(r)

$L(\epsilon) = \{\epsilon\}$
$L(a) = \{a\},\forall a \in \Sigma$
$L((r)) = L(r)$
$L(r|s)=L(r)\cup L(s)$ $L(rs)=L(r)L(s)$ $L(r*)=(L(r))*$

下面是常用到的正则表达式符号以及对应的含义:

符号	含义	例子	例子含义
`a`	匹配字符本身	`a`	匹配字符 a
`.`	匹配除换行符以外的任意单个字符	`a.b`	如 acb、a1b
`r\|s`	或 / 选择	`a\|b`	匹配 a 或 b
`r*`	前面的表达式重复 0 次或多次	`a*`	“"、a、aa、…
`r+`	前面的表达式重复 1 次或多次	`a+`	a、aa、…
`r?`	前面的表达式出现 0 次或 1 次	`a?`	"” 或 a
`(r)`	和r相同	`(ab)*`	“"、ab、abab、…
`[s]`	字符集合，匹配其中任意一个字符	`[abc]`	a、b 或 c
`[^s]`	字符集合取反	`[^abc]`	除 a、b、c 外的字符
`^`	通常表示字符串/行开头	`^abc`	以 abc 开头
`$`	通常表示字符串/行结尾	`abc$`	以 abc 结尾
`\`	转义特殊字符	`\*`	匹配字符 * 本身
`r{m}`	恰好重复 m 次	`a{3}`	aaa
`r{m,n}`	重复 m 到 n 次	`a{2,4}`	aa、aaa、aaaa
`"s"`	串s的字面值	`"*a"`	*a

NFA 非确定性有穷自动机

我们定义非确定性有穷自动机A是一个五元组 $A = (\Sigma,S,s_0,\delta,F)$:

字母表 $\Sigma\ \ (\epsilon \notin \Sigma)$
有穷的状态集合 S
唯一的初始状态 $s_0$
状态转移函数 $\delta$：$\delta: S\times(\Sigma \cup \{\epsilon\})\to 2^S$
接受状态集合 $F \subseteq S$

NFA的主要特点是一个输入可以有多个下一状态，且允许 $\epsilon$转移

自动机A定义了一种语言 L(A),它能接受的所有字符串构成的集合

DFA 确定性有穷自动机

我们定义确定性有穷自动机A是一个五元组 $A = (\Sigma,S,s_0,\delta,F)$:

字母表 $\Sigma\ \ (\epsilon \notin \Sigma)$
有穷的状态集合 S
唯一的初始状态 $s_0$
状态转移函数 $\delta$：$\delta: S\times \Sigma \to S$
接受状态集合 $F \subseteq S$

与NFA不同的点在于DFA一个输入只有一个状态，不允许空转移

NFA简洁易于理解，便于描述语言L(A)，而DFA容易判断 $x \in L(A)$,适合产生词法分析器

因此我们通常用NFA描述语言，DFA实现词法分析器

词法分析生成器的基本原理（2）

在上一节中我们提到了Regix以及NFA，DFA的基本含义，我们接下来介绍他们之间的相互转化。

从RE到NFA: Thompson 构造法

Thompson构造法的基本思想是按结构归纳，即把正则表达式递归地拆分成小的子表达式，每个子表达式先构造一个小NFA，再通过 $\epsilon$边把这些小的NFA连接起来。

依据正则表达式的定义，我们可以拆开看:

基本字符:

对于一个字符a，我们可以构造:

1
2


 a
(q0) ---> (q1)

其中q0是入口，q1是出口

连接:rs

假设我们已经构造好了正则表达式r和s的NFA，那么对于连接我们可以通过将r的出口和s的入口以一个 $\epsilon$边连接即可:

1
2


 r s
 --> [ NFA ] --ε--> [ NFA ] -->

选择 r|s

我们此时希望NFA可以选择走r的入口，也可以走s的入口，那么我们只需要新建一个入口和一个新的出口，并用 $\epsilon$边将他们分别与r和s的入口，出口连接即可

1
2
3
4
5


 ε --> [NFA(r)] --ε
 / \
start --- ---> end
 \ /
 ε --> [NFA(s)] --ε

Kleene 星号: r*

对于Kleene星号，我们需要具备两种能力，即一次都不执行和执行完以后重新执行:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 ε
 +-------------> end
 |
 start
 |
 | ε
 v
 start_r ---- r ----> end_r
 ^ |
 |_______ ε _________|
 |
 ε
 |
 v
 end

前者我们通过将新的入口和新的出口直接通过 $\epsilon$边连接完成，后者我们则在r的NFA上加入一条由出口指向入口的 $\epsilon $边。

我们可以通过下面这个例子来展示Thompson构造法转化RE到NFA的完整流程:

假设我们有正则表达式a(b|c)*

我们可以先按照语法树来决定构造顺序：

1
2
3
4
5
6
7
8
9


 连接
 / \
 a *
 |
 |
 |
 b|c
 / \
 b c

然后我们可以自底向上构造，首先构造一下a,b,c：

1
2
3
4
5


a → NFA(a)

b → NFA(b)

c → NFA(c)

接下来构造b|c:

1
2
3


 /-- b --\
-- ε - - ε -->
 \-- c --/

然后给b|c套上Kleene星号:

1
2
3
4
5
6
7


 ε----------------------+
 | |
 v |
start --> [ b|c ] --> merge ---+
 | |
 +----------ε----------------> end
 merge --ε-----> end

最后再把a的按照连接的方式连起来:

1

start --> [a] --> [(b|c)*] --> end

从NFA到DFA:子集构造法

子集构造法的核心思想在于DFA的一个状态，对应于NFA的一组状态。

由于DFA在描述状态转移时只允许目标状态有且仅有一个，而NFA可以有多个，因此我们干脆把NFA中所有可能的状态整体看成DFA的一个状态。

在描述具体方法前，我们通过上面的NFA介绍两个名词:

$\epsilon-\text{closure}$：表示在NFA中从状态集合S出发，只走任意条 $\epsilon$边，能够到达的状态，包括S自己。

例如下图中，从状态 $q_0$出发，只走任意条 $\epsilon$边，能够到达的状态为: $\{q_0,q_1,q_2,q_4,q_7\}$,因此我们有: $\epsilon-\text{closure}(\{q_0\})=\{q_0,q_1,q_2,q_4,q_7\}$

Move: 表示在NFA中从状态集合S出发，读取字符 a一步后能到达的状态集合

借用这两个名词，以及上面这个例子，我们可以很好的描述子集构造法的流程了。

首先，从初始状态出发，计算: $\epsilon-\text{closure}(q_0)$,计算出来后记作初始状态 $D_0 = \{q_0,q_1,q_2,q_4,q_7\}$

之后从 $D_0$读字符a，算 $\epsilon-\text{closure}(\text{move}(D_0,a)) = D_1 = \{q_1,q_2,q_3,q_4,q_6,q_7,q_8\}$

接着从 $D_0$读字符b，得到 $D_2 = \{q_1,q_2,q_4,q_5,q_6,q_7\}$

再从 $D_1$读字符a，算 $\epsilon-\text{closure}(\text{move}(D_1,a)) = \{q_1,q_2,q_3,q_4,q_6,q_7,q_8\} = D_1$

再从 $D_1$读取字符b，算 $\epsilon-\text{closure}(\text{move}(D_1,b))=D_3=\{q_1,q_2,q_3,q_4,q_5,q_6,q_7,q_9\}$

然后从 $D_2$读字符a，得到 $D_1$，从 $D_2$读字符b，得到 $\epsilon-\text{closure}(\text{move}(D_2,b)) = D_2 = \{q_1,q_2,q_4,q_5,q_6,q_7\}$

最后从 $D_3$读字符a，得到 $D_1$ ，从 $D_3$读字符b，得到 $\epsilon-\text{closure}(\text{move}(D_3,b)) = D_4^* = \{q_1,q_2,q_4,q_5,q_6,q_7,q_{10}\}$,因为它包含终态 $q_{10}$，所以我们会给它一个特殊的标记。

而从 $D_4$读字符a和字符b分别可以得到 $D_1,D_2$

总结下来，我们可以得到如下状态转移图:

DFA 状态	对应 NFA 状态集合	a	b
$D_0$	{0,1,2,4,7}	$D_1$	$D_2$
$D_1$	{1,2,3,4,6,7,8}	$D_1$	$D_3$
$D_2$	{1,2,4,5,6,7}	$D_1$	$D_2$
$D_3$	{1,2,4,5,6,7,9}	$D_1$	$D_4$
$D_4^*$	{1,2,4,5,6,7,10}	$D_1$	$D_2$

转化为DFA，可以画成:

最小化DFA

DFA最小化的目标是在保持语言完全不变的前提下，把行为等价的DFA状态合并，得到状态数最少的DFA。

首先，我们需要明确什么叫两个状态是等价的:

我们假设DFA中存在两个状态p,q。从他们出发，如果输入任意的字符串w，最终要么都接受，要么都拒绝，那么我们可以认为: $p\equiv q $。

知道了怎样的状态是等价，也就是可以合并的，我们可以开始考虑怎么最小化DFA了。

首先我们可以知道的是，接受状态和非接受状态是不可合并的，因此我们可以把DFA的状态集合分为两组:

$$ P_0 = \{F,Q-F\} $$

接下来则可以进一步不断细分，我们对于同一组中的两个状态p和q，观察他们读入每个字符后的去向。如果:

$$ \delta(p,a) =\epsilon-\text{closure}(\text{move}(p,a)) \neq \delta(q,a) $$

那么此时p和q不能继续待在一个组，于是把他们拆开。

不断重复上述流程，直至无法继续拆分为止。

最终每一个分组中状态都是等价状态，可以合并为一个DFA状态。

为了方便我们理解，我们利用我们上面根据子集构造法得到的DFA来做一遍上述流程。

状态	a	b	是否接受
$D_0$	$D_1$	$D_2$	否
$D_1$	$D_1$	$D_3$	否
$D_2$	$D_1$	$D_2$	否
$D_3$	$D_1$	$D_4$	否
$D_4$	$D_1$	$D_2$	是

其中唯一接受状态： $F = \{D_4 \}$

第一步，按接受/不接受进行第一步划分，得到:

$$ P_0 = \{ \{D_4\},\{D_0,D_1,D_2,D_3\}\} $$

为了方便，我们记作: $P_0 = \{A,B\},A=\{ D_4\}$

第二步，检查B是否可以进一步拆分。

$D_0$: 根据表格，我们发现无论输入a还是b，最后仍然落入B中，因此我们记作: $D_0:(B,B)$
$D_1$: 类似的，我们可以得到: $D_1:(B,B)$
$D_2$: $D_2:(B,B)$
$D_3$: $D_3(B,A)$

于是我们发现只有 $D_3$与B中的其他状态不同，因此我们可以进一步划分出:

$$ P_1 = \{\{D_4\},\{D_3\},\{D_0,D_1,D_2\}\} $$

接着，我们继续检查 $C=\{D_0,D_1,D_2\}$,按照上面的流程，我们可以得到:
$D_0:(C,C)$ $D_1:(C,B)$ $D_2:(C,C)$

发现 $D_1$，不同因此继续拆分: $P_2 = \{\{D_4\},\{D_3\},\{D_1\},\{D_0,D_2\}\}$

最后，我们可以发现 $D_0,D_2$显然是不可拆分的，他们是等价的，因此我们得到了最小的DFA状态:

$$ S_0 = \{D_0,D_2\},S_1=\{D_1\},S_2=\{D_3\},S_3=\{D_4\} $$

其中 $S_3$是终态，我们可以得到状态转移表格:

状态	a	b
$S_0$	$S_1$	$S_0$
$S_1$	$S_1$	$S_2$
$S_2$	$S_1$	$S_3$
$S_3^*$	$S_1$	$S_0$

画成DFA就是

[从零开始的编译原理][实验] Exp Chapter 0：实验环境搭建

Mon, 28 Sep 2026 16:36:25 +0800

Docker配置

根据课程指导书的要求，我们通过Docker拉取对应的镜像:

1

docker pull maxxing/compiler-dev

下面简单介绍一下Docker的使用方法。

首先我们需要简单区分一下镜像(image)和容器(container),前者可以看作是一个硬盘，里面装好了操作系统，但它是静态的，不能直接拿来运行。而后者则是一台计算机，里面装了硬盘，就能运行对应的操作系统。

在实际情况中，我们可以在容器中对文件系统进行修改，例如创建和删除文件，但是镜像不会受到影响。

通常而言，我们只希望在镜像的环境做一些一次性的工作，比如用里面的测试脚本来测试自己的编译器，然后查看测试结果。在此之后这个临时容器就没有任何作用了。

例如我们希望在上面image的环境中执行如下命令:ls -l /，那么我可以输入指令:

1

docker run maxxing/compiler-dev ls -l /

然后此时终端就会显示命令ls -l /的结果，此时会生成一个临时容器，我们可以用指令:docker ps -a查看:

1
2
3


user@macbook compiler % docker ps -a 
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
441f432b9731 maxxing/compiler-dev "ls -l" 3 seconds ago Exited (0) 3 seconds ago hopeful_shannon

那么我们可以通过指令:docker rm 441f432b9731来删除这个容器。

当然我们还可以将上述执行命令-删除临时容器的操作合并为一个指令:

1

docker run --rm maxxing/compiler-dev ls -l /

这样创造临时容器，运行完指令后，就会直接把临时容器给删掉了。

有时候，可能我们期望在容器中执行的命令很复杂，不能一行输入完整，那么此时我们可以使用

1

docker run -it --rm maxxing/compiler-dev bash

这样我们就创建了临时容器后，执行了bash指令，就可以在容器内的shell中工作输入任何指令了。其中-it参数是为了开启容器的stdin。

如果需要退出，直接输入exit即可

在大部分情况下，我们还希望Docker容器能够访问宿主机中的文件，如我们实现的编译器位于宿主机的/path/to/compiler目录下，我们希望 Docker 容器也能访问到这个目录里的内容, 这样你就可以使用容器中的测试脚本测试你的编译器了. 可以执行:

1

docker run -it --rm -v /path/to/compiler:/root/compiler maxxing/compiler-dev bash

这条命令多了一个-v参数，它的作用是把宿主机的某个目录挂载到容器的某个目录（例如上面指令是/root/compiler）。这样，在进入容器之后，就可以通过访问挂载的目录访问宿主机的目录了。

Koopa IR介绍

Koopa IR是一种简化后的中间表示，在设计上类似LLVM IR。同时我们在后续lab中会用到对应的框架:

https://github.com/pku-minic/koopa

Koopa IR 是一种强类型的 IR, IR 中的所有值 (Value) 和函数 (Function) 都具备类型 (Type).

Koopa IR 中, 基本块 (basic block) 必须是显式定义的. 即, 在描述函数内的指令时, 你必须把指令按照基本块分组, 每个基本块结尾的指令只能是分支/跳转/函数返回指令之一. 在 IR 的数据结构表示上, 指令也会被按照基本块分类. 这很大程度上方便了 IR 的优化, 因为许多优化算法都是在基本块的基础上对程序进行分析/变换的.

假设我们有一个用Koopa IR编写的程序（见指导书中的"hello world!"），我们将其保存在了文件hello.koopa中，那么我们可以在实验环境中运行这个koopa IR程序:

1
2
3


koopac hello.koopa | llc --filetype=obj -o hello.o
clang hello.o -L$CDE_LIBRARY_PATH/native -lsysy -o hello
./hello

RISC-V介绍

我们的编译器最终会生成RISC-V汇编。

RISC-V的指令系统由

基础指令系统 (base instruction set) 和指令系统扩展 (extension) 构成. 每个 RISC-V 处理器必须实现基础指令系统, 同时可以支持若干扩展. 常用的基础指令系统有两种:

RV32I: 32 位整数指令系统.
RV64I: 64 位整数指令系统. 兼容 RV32I.

常用的标准指令系统扩展包括:

M 扩展: 包括乘法和除法相关的指令.
A 扩展: 包括原子内存操作相关的指令.
F 扩展: 包括单精度浮点操作相关的指令.
D 扩展: 包括双精度浮点操作相关的指令.
C 扩展: 包括常用指令的 16 位宽度的压缩版本.

我们通常使用 RV32/64I + 扩展名称的方式来描述某个处理器/平台支持的 RISC-V 指令系统类型, 例如 RV32IMA 代表这个处理器是一个 32 位的, 支持 M 和 A 扩展的 RISC-V 处理器.

在我们的Lab中，我们编译器将生成RV32IM范围内的RISC-V汇编。

假设我们有一段RISC-V的汇编程序:hello.S，我们可以在实验环境中将这个RISC-V程序汇编并链接为可执行文件并运行起来:

1
2
3


clang hello.S -c -o hello.o -target riscv32-unknown-linux-elf -march=rv32im -mabi=ilp32
ld.lld hello.o -L$CDE_LIBRARY_PATH/riscv32 -lsysy -o hello
qemu-riscv32-static hello

编程语言选择

为了方便起见，我最终还是选择使用C++进行开发。

我们使用CMake模版:https://github.com/pku-minic/sysy-cmake-template

配置好环境后，我们可以进入docker环境中，执行命令:

1
2


cmake -DCMAKE_BUILD_TYPE=Debug -B build
cmake --build build

构建编译器，后续如果我们更改了代码，则仅仅需要通过:

1

cmake --build build

即可。