企业官网建设流程全解析

简介：一份小型C编译器源代码，面向希望从实践层面理解编译原理、夯实C语言底层机制的学习者与开发者，可用于词法分析、语法分析、语义检查、基础优化到目标代码生成等环节的对照研读。压缩包共86个文件、约210KB，以50个C源文件与12个头文件为核心，辅以8个Pascal文件、5个TXT说明、3个批处理脚本及Makefile、配置文件等，兼顾实现代码、构建入口与文档线索。已有480人学习，适合作编译技术入门与课程实验参考。通过梳理其解析器、符号表、表达式处理和针对特定架构的代码生成模块，读者可观察C语言指针、结构体、函数调用等特性如何落地，并据此开展修改、调试与轻量优化，积累编译器实现与排错经验。

1. 拿到一份小型C编译器源码，先看它能编译什么样的程序

很多人对C语言编译器的印象停留在“巨大、神秘、碰不得”，其实把预处理器、优化器这些剥掉，一个能跑的小型C语言编译器源码，核心链路并不长：读字符、切 token、建语法树、查符号表、吐目标代码。这份源码干的就是这件事，它面向的是想搞懂编译原理怎么落地、又不想一头扎进工业级编译器几十万行代码里的开发者。适合谁？写过 C、能看懂递归和链表、被编译原理课的理论绕晕过、想亲手改一条语法规则看结果的人。它不追求完整标准，追求的是每个阶段都能读、能断点、能改。你拿到手第一件事不是通读，而是找一条最小用例，比如return 1+2*3;，跟着它从字符一路走到结果，先建立整条链路的体感。

2. 编译器骨架拆解：五个阶段如何串成一条从源码到结果的链路

先别急着看某个函数写得精不精，先认清这套代码的阶段划分。小型 C 编译器不管用什么宿主语言实现，骨架基本都是前端三段加后端两段：词法分析、语法分析、语义分析、中间表示、代码生成。有的项目会把语义分析揉进语法分析里，一边建树一边查符号，这不算错，但调试时会比较难受，因为报错位置和建树逻辑搅在一起。我一般建议读者先找到入口文件，看它按什么顺序调用各模块，那个顺序就是这套源码的“主心骨”。

2.1 目录结构与模块职责：先认清哪块该改

这类项目的目录不会很深，常见形态是一个src/放核心代码，一个test/放用例，根目录一个 Makefile 或 CMakeLists。文件名可能叫lexer.c、parser.c、ast.c、symtab.c、type.c、codegen.c、main.c，也可能把词法和语法合在parse.c里。你对照下面这张表找自己那份源码的对应文件，名字不同没关系，职责基本逃不出这几类。

改动频率这一列值得留意：parser 和 codegen 是二次开发的主战场，你加任何语法特性，这两处几乎都要动；symtab 和 type 次之；main.c 和 Makefile 基本一次性写好就不碰了。读懂这个分布，你就知道时间该花在哪。

入口文件的主流程通常长这样，我按最常见的 C 实现风格写出来，你对照自己那份源码看函数名即可：

int main(int argc, char **argv) { if (argc != 2) { fprintf(stderr, "usage: cc <file.c>\n"); return 1; } char *src = read_file(argv[1]); // 一次性读入，前端不需要流式处理 if (!src) { fprintf(stderr, "cannot open %s\n", argv[1]); return 1; } Token *tok = tokenize(src); // 阶段一：词法，产出 token 链表 Node *prog = parse(tok); // 阶段二：语法，产出顶层声明链表 resolve(prog); // 阶段三：语义，绑定变量、填类型和栈偏移 codegen(prog); // 阶段四：后端，输出类汇编 return 0; }

这段代码里几个参数和返回值值得说清楚。read_file返回的缓冲区在整条链路里都被 token 的loc指针引用，所以中途不能释放，报错打印时靠它定位原始文本。tokenize返回的是链表头而不是数组，原因是递归下降解析器只需要单向前进，链表天然支持“吃掉一个 token 就往后挪一格”，省掉了维护下标的麻烦。parse返回的是顶层声明链表，函数定义、全局变量都挂在这条next链上。resolve一般要跑两遍：第一遍收集所有函数签名和全局符号，第二遍再进函数体做检查，否则前向调用会报“未声明”。codegen直接往标准输出打印，方便你用重定向存成.s文件再交给系统汇编器。

提示：如果你的入口函数里没有单独的resolve，而是把语义检查塞在parse内部，别急着改架构。先按现有顺序跑通一条用例，等你要加类型系统时再拆，拆的时候把“建树”和“查符号”分成两个遍历就行。

2.2 一条源码到可执行结果的完整链路

拿int main() { int a = 1 + 2 * 3; return a; }走一遍，你能直观看到每个阶段吃什么、吐什么。词法阶段把它切成int、main、(、)、{、int、a、=、1、+、2、*、3、;、return、a、;、}这样一串带行号的 token。语法阶段把这串东西组织成一棵以函数定义为根的树，函数体里挂一条语句链：变量声明语句、返回语句。语义阶段给a分配栈偏移，给1+2*3的每个子表达式填上int类型，检查return的表达式类型和函数返回类型是否匹配。代码生成阶段把树后序遍历成指令序列，先算2*3压栈，再算1压栈，弹出相加，最后存到a的栈槽，再把a读出来放进返回值寄存器。

各阶段的输入输出和典型失败表现可以列成这样，排查时按这张表定位问题出在哪一层：

这里有个血泪经验：报错信息一定要带行号，而且行号要在词法阶段就记进 token。我见过不少小型实现只在 parser 里报“unexpected token”，不带位置，一旦用例大一点，你就得靠肉眼数第几个字符，纯纯的折磨。行号维护的成本极低，扫描时遇到\n就自增，收益却很高。

2.3 前后端边界：为什么小型编译器常把后端做成栈式

这套源码的后端大概率是栈式的：表达式求值的结果压栈，二元运算弹两个压一个，局部变量用基址寄存器加偏移访问。原因不复杂，栈式后端不需要寄存器分配，指令选择也少，正确性容易验证。寄存器分配是个深坑，小型项目没必要碰。你会在codegen.c里看到大量push、pop，以及一个递增的标签计数器用来生成if、while的跳转标号。

这种设计的代价是生成的代码效率一般，但对学习和小规模程序完全够用。我在读这类代码时习惯先确认两件事：一是表达式求值后栈上净增一个值这条不变式有没有守住，二是每个语句执行完栈有没有回到进入时的状态。这两条守住了，后端基本不会出玄学问题；守不住，就会出现“跑十次对九次”的鬼故事，最后发现是某个分支漏了一次 pop。

3. 词法与语法分析：手写扫描器和递归下降解析器怎么落地

前端这两块是整套源码里最值得逐行读的部分。它们没有复杂的数据结构，但边界条件特别多，读懂了你自己写个小 DSL 的解析器毫无压力。下面按 token 定义、扫描循环、表达式分层、AST 设计四个点拆。

3.1 词法分析器：状态机怎么切出 token

token 的定义决定了后面所有模块的接口。常见写法是用一个枚举区分种类，结构体里带链表后继、原始位置、长度和行号：

typedef enum { TK_IDENT, // 标识符 TK_NUM, // 整数字面量 TK_PUNCT, // 运算符与分隔符 TK_KEYWORD, // 关键字 TK_EOF // 结束标记，parser 靠它收尾 } TokenKind; typedef struct Token Token; struct Token { TokenKind kind; Token *next; // 链表后继，parser 单向前进 int val; // TK_NUM 时的数值 char *loc; // 指向源码缓冲区，报错时打印原文 int len; // token 长度 int line; // 行号 };

扫描主循环是一个大 if-else 链，跳过空白和注释，然后按首字符分流。数字走strtol，标识符走字母下划线循环加关键字表比对，剩下的都归为运算符，但要注意多字符运算符必须先长后短匹配：

Token *tokenize(char *p) { Token head = {0}; Token *cur = &head; int line = 1; while (*p) { if (*p == '\n') { line++; p++; continue; } if (isspace(*p)) { p++; continue; } if (p[0] == '/' && p[1] == '/') { // 行注释 while (*p && *p != '\n') p++; continue; } Token *t = calloc(1, sizeof(Token)); t->loc = p; t->line = line; if (isdigit(*p)) { t->kind = TK_NUM; t->val = strtol(p, &p, 10); // strtol 直接推进 p t->len = p - t->loc; } else if (isalpha(*p) || *p == '_') { char *start = p; while (isalnum(*p) || *p == '_') p++; t->len = p - start; t->kind = is_keyword(start, t->len) ? TK_KEYWORD : TK_IDENT; } else { t->kind = TK_PUNCT; t->len = punct_len(p); // 先匹配 == <= && 这类双字符 p += t->len; } cur = cur->next = t; } Token *eof = calloc(1, sizeof(Token)); eof->kind = TK_EOF; eof->loc = p; eof->line = line; cur->next = eof; return head.next; }

几个参数说明一下。strtol(p, &p, 10)的第二个参数是出参，直接把p推到数字末尾，省掉手写循环，但要注意它不检查溢出，教学项目够用。is_keyword接收起始指针和长度，内部用长度加memcmp比对，避免为了比较而临时拷贝字符串。punct_len是关键函数，必须先匹配双字符再匹配单字符，否则==会被切成两个=，parser 那边就会莫名其妙地报错。最后的TK_EOF必须补，而且loc指向缓冲区末尾，因为 parser 的主循环靠它判断“还有没有东西可读”，漏了就是越界读一个野指针，段错误来得毫无征兆。

3.2 递归下降解析：表达式优先级用函数层级表达

表达式解析的经典写法是每个优先级一个函数，从低到高串起来：赋值、相等比较、关系比较、加减、乘除、一元、基本表达式。低优先级函数调用高优先级函数，自己在中间处理本层的运算符。左结合用循环，右结合用递归，这一点搞反了结果就错，而且错得很隐蔽。

// 入口：整个表达式从赋值层开始 Node *expr(Token **rest, Token *tok) { return assign(rest, tok); } Node *assign(Token **rest, Token *tok) { Node *node = equality(&tok, tok); if (equal(tok, "=")) { Node *rhs = assign(&tok, tok->next); // 赋值右结合 *rest = tok; return new_binary(ND_ASSIGN, node, rhs); } *rest = tok; return node; } Node *mul(Token **rest, Token *tok) { Node *node = unary(&tok, tok); for (;;) { if (equal(tok, "*")) { node = new_binary(ND_MUL, node, unary(&tok, tok->next)); continue; } if (equal(tok, "/")) { node = new_binary(ND_DIV, node, unary(&tok, tok->next)); continue; } *rest = tok; // 本层没有运算符了，交还剩余 token return node; } }

Token **rest这个出参是这套写法的核心约定：函数不修改调用者持有的 token 指针，而是把“吃剩下的位置”通过rest写回去；只有成功消费了 token 才更新rest。这样上层拿到返回值时，能准确知道解析停在哪。equal(tok, "*")只看种类和文本，不消费，消费靠tok->next。乘除层用for(;;)循环实现左结合，赋值层用递归实现右结合，这个对比就是整个表达式解析的精髓。你调试1-2-3这类用例时，如果结果不对，先看减法层的循环有没有写成递归。

3.3 AST 节点设计：用 tagged union 还是一个大结构体

C 里没有继承，AST 节点通常用枚举加结构体，把所有可能用到的字段都塞进去，简单直接，调试时打印方便。字段多看起来浪费内存，但小型编译器处理的源文件就几千行，这不是瓶颈。

typedef enum { ND_NUM, ND_VAR, ND_ADD, ND_SUB, ND_MUL, ND_DIV, ND_EQ, ND_LT, ND_ASSIGN, ND_IF, ND_FOR, ND_WHILE, ND_RETURN, ND_BLOCK, ND_CALL } NodeKind; struct Node { NodeKind kind; Node *next; // 语句链的下一条 Node *lhs, *rhs; // 二元运算、赋值、比较 Node *cond; // if / while 条件 Node *then, *els; // if 的两个分支 Node *body; // 循环体或代码块 Node *init, *inc; // for 的初始化与步进 Node *args; // 调用实参链 char *name; // 变量名或函数名 int val; // 常量值 Type *ty; // 语义阶段填类型 int offset; // 局部变量相对基址的偏移 };

next用来串语句链，lhs和rhs用来表达二元关系，body挂代码块里的语句链，args挂实参链。语义分析前ty和offset都是空或零，语义分析时填上，代码生成直接读，省得再查一遍符号表。这种“一遍建树、二遍注解、三遍生成”的分法，调试时每步都能打印树看，比把逻辑全糊在一起强得多。我一般会写一个print_ast函数，带缩进递归输出，遇到类型不对的用例，先看树长什么样，比单步跟踪快。

4. 语义与代码生成：符号表、类型检查和栈式后端

前端把树建起来只是第一步，树上的名字还没有绑定到具体存储位置，表达式的类型也没确定。语义分析干的就是这两件事，代码生成再把注解过的树翻译成指令。这两块合起来是整套源码里最容易出“看起来对、跑起来错”的地方。

4.1 符号表与作用域链：变量名怎么落到栈偏移

小型编译器一般用链表实现作用域，每进一个{}压一层，出去弹一层，查找从内向外走：

typedef struct VarScope { char *name; Type *ty; int offset; // 相对基址的偏移，负数向下增长 struct VarScope *next; } VarScope; typedef struct Scope { struct Scope *parent; VarScope *vars; } Scope; static Scope *scope = &(Scope){0}; void enter_scope(void) { Scope *sc = calloc(1, sizeof(Scope)); sc->parent = scope; scope = sc; } void leave_scope(void) { scope = scope->parent; } VarScope *find_var(char *name) { for (Scope *sc = scope; sc; sc = sc->parent) for (VarScope *v = sc->vars; v; v = v->next) if (!strcmp(v->name, name)) return v; return NULL; }

enter_scope和leave_scope必须和语法上的花括号严格配对，函数体、if 体、while 体、裸块都要包。局部变量声明时分配offset，一般从一个负数开始往下减，比如第一个变量-4，第二个-8，因为栈向低地址增长。find_var从当前层往外找，找到就返回，天然实现变量遮蔽。这里有个容易翻车的点：解析函数体时如果只enter_scope没leave_scope，后面所有函数都会看到前一个函数的局部变量，现象是“两个函数里的同名变量互相串值”，而且很难从输出反推原因。

4.2 类型检查与隐式转换：别让指针算术成为漏网之鱼

类型表示可以很简单，一个种类枚举加基类型指针和大小就够了：

typedef enum { TY_INT, TY_CHAR, TY_PTR, TY_FUNC } TypeKind; struct Type { TypeKind kind; Type *base; // 指针或函数返回类型 int size; // 字节数，指针算术靠它缩放 };

类型检查写成对树的后序遍历，子节点先填好类型，再根据节点种类推导自己的类型。常量是int，变量查符号表，二元运算里如果有一边是指针，结果还是指针，赋值时检查两边类型是否兼容。指针算术是小型编译器最常漏的地方：p + 1里的 1 要乘以base->size，不乘的话指针偏移就是按字节走，读结构体或数组时结果全错，而且错得很有规律，容易误判成“内存布局问题”。

void add_type(Node *n) { if (!n || n->ty) return; add_type(n->lhs); add_type(n->rhs); switch (n->kind) { case ND_NUM: n->ty = ty_int; return; case ND_VAR: { VarScope *v = find_var(n->name); if (!v) error("undefined variable: %s", n->name); n->ty = v->ty; return; } case ND_ADD: if (n->lhs->ty->kind == TY_PTR) { n->ty = n->lhs->ty; return; } n->ty = ty_int; return; default: n->ty = ty_int; return; } }

if (!n || n->ty) return这一行防了两件事：空指针和重复遍历。语义阶段可能被调用多次，已经填过类型的节点直接跳过，避免重复报错。error函数最好带行号，行号从节点关联的 token 拿，所以建树时要把 token 的位置存进节点，这也是为什么很多实现在Node里多留一个Token *tok字段。

4.3 代码生成：从 AST 到类汇编指令序列

栈式后端的核心不变式是“每条表达式生成完，栈顶多一个值”。二元运算先生成左子树，再生成右子树，然后弹右、弹左、算、压结果：

void gen_expr(Node *n) { switch (n->kind) { case ND_NUM: printf(" push $%d\n", n->val); return; case ND_VAR: printf(" push %d(%%rbp)\n", n->offset); return; case ND_ADD: case ND_SUB: case ND_MUL: case ND_DIV: gen_expr(n->lhs); gen_expr(n->rhs); printf(" pop %%rdi\n"); // 右操作数 printf(" pop %%rax\n"); // 左操作数 if (n->kind == ND_ADD) printf(" add %%rdi, %%rax\n"); else if (n->kind == ND_SUB) printf(" sub %%rdi, %%rax\n"); else if (n->kind == ND_MUL) printf(" imul %%rdi, %%rax\n"); else printf(" cqo\n idiv %%rdi\n"); printf(" push %%rax\n"); return; case ND_ASSIGN: gen_addr(n->lhs); // 左值地址压栈 gen_expr(n->rhs); printf(" pop %%rdi\n"); printf(" pop %%rax\n"); printf(" mov %%rdi, (%%rax)\n"); printf(" push %%rdi\n"); // 赋值表达式的值 return; } }

先左后右、先弹右再弹左，这个顺序是为了让sub和idiv的方向正确：rax放左操作数，rdi放右操作数，sub %rdi, %rax才是左减右。除法要先cqo做符号扩展，否则负数除法会得到奇怪的结果。赋值表达式要返回赋进去的值，所以最后还要把值压回栈，这也是为什么a = b = 3能链式工作。语句层再写一个gen_stmt，处理if、while、return和块，跳转标签用一个全局计数器生成.L1、.L2这种唯一名字。每个语句生成完，栈必须回到进入时的深度，否则函数返回时栈指针错位，程序会以各种离奇方式崩溃。

5. 跑起来与排查：构建、测试矩阵和几类高频翻车

源码读得差不多了，该让它跑起来。这类项目的构建通常很朴素，一个 Makefile，几个源文件编成一个可执行程序，运行时接收一个.c文件路径，输出类汇编到标准输出。你需要的是一条从源码到可执行结果的完整命令链，以及一套能快速定位问题的用例。

5.1 构建与运行：三条命令走通最小闭环

先看 Makefile 里有没有all、clean目标，编译选项里有没有-g。有-g才能用 gdb 看栈，调 parser 的时候这是刚需。

make # 生成编译器可执行文件，通常叫 cc 或 mycc ./cc test/arith.c > out.s # 输出类汇编 cc -o out out.s && ./out # 交给系统汇编器链接并运行 echo $? # 查看程序返回值，验证结果

如果你的实现是直接解释执行 AST，那第二条命令就变成./cc test/arith.c，直接打印结果或返回值。两种形态都常见，解释执行省掉汇编器依赖，生成汇编则更接近真实编译器的形态。跑通之后，把test/下的用例逐个过一遍，别只跑一个就以为万事大吉，小型编译器的 bug 往往藏在边界用例里。

注意：生成的.s文件如果用了系统汇编器不认识的语法，先确认输出是 AT&T 还是 Intel 风格，以及目标平台是 x86-64 还是别的架构。跨平台问题在这一步暴露最直接。

5.2 测试用例矩阵：从表达式到递归函数

按覆盖点设计用例，比漫无目的地试要高效。下面这张表是我一般会先跑的一轮，覆盖优先级、结合性、控制流、函数调用和指针五类：

自动化方式很朴素，写个 shell 脚本，每个用例编译运行拿退出码，和预期比对：

for f in test/*.c; do ./cc "$f" > tmp.s || { echo "COMPILE FAIL $f"; continue; } cc -o tmp tmp.s && ./tmp got=$? want=$(basename "$f" .c | cut -d_ -f2) # 约定文件名带期望值 [ "$got" = "$want" ] || echo "MISMATCH $f: got $got want $want" done

这个脚本把文件名里的期望值抽出来做比对，改用例时不用改脚本。差分测试是更稳的办法：同一批源码分别用系统编译器和自研编译器跑，比较退出码和标准输出，任何不一致都值得看一眼。

5.3 常见问题排查：五条踩坑记录

现象一：第一个用例就段错误，gdb 栈停在主表达式解析函数。原因多半是 token 链表末尾没有TK_EOF，parser 在文件结束时还去解引用tok->next，拿到空指针。解决是把 EOF 补进tokenize的返回值，并且在primary的默认分支里直接报错，而不是返回空指针让上层继续用。

现象二：1-2-3算出来是 2 而不是 -4。原因是减法层写成了递归右结合，等价于1-(2-3)。解决是把加减乘除层统一改成for(;;)循环，只有赋值和三元运算才用递归右结合。这个 bug 很隐蔽，因为1+2+3两种写法结果一样，只有减法和除法才暴露。

现象三：两个函数里的同名局部变量互相污染。原因是解析函数体时进了作用域但没出来，或者leave_scope写在了错误的分支上。解决是检查每个enter_scope是否有配对的leave_scope，并在find_var里加临时打印，看查找到底命中了哪一层的变量。

现象四：带参数的函数调用返回垃圾值。原因是调用约定不统一：调用者压了参数但没清栈，或者被调用者没把返回值放进rax。解决是定死一套约定，参数从右往左压，调用完add $N*8, %rsp清栈，返回值统一放rax，两端都按这个写，别一边改一边不改。

现象五：源文件超过一百多个 token 就崩溃。原因是 token 用固定大小数组存，越界写坏了堆。解决是改成链表，或者动态realloc扩容。这类问题在小编译器里很常见，因为作者只拿短用例测过。

6. 二次开发：给编译器加一条 for 循环语法的完整改造路径

加语法特性是检验你是否真读懂这套源码的最好方式。以for循环为例，最省事的做法不是在后端新增节点，而是在 parser 里把它降级成while加初始化语句，这样代码生成完全不用动。改动词法关键字表，让for被识别为关键字；在 parser 的语句分发处加一个分支；解析三个表达式和循环体；最后构造节点。

// for (init; cond; inc) body => init; while (cond) { body; inc; } Node *parse_for(Token **rest, Token *tok) { tok = skip(tok, "for"); tok = skip(tok, "("); Node *init = expr(&tok, tok); tok = skip(tok, ";"); Node *cond = expr(&tok, tok); tok = skip(tok, ";"); Node *inc = expr(&tok, tok); tok = skip(tok, ")"); Node *body = parse_stmt(&tok, tok); Node *node = new_node(ND_WHILE); node->cond = cond; node->body = new_block(body, inc); // 循环体执行完再执行步进 node->init = init; // 交给外层块语句按顺序执行 *rest = tok; return node; }

skip是“断言当前 token 是指定文本并前进一格”的辅助函数，失败就报语法错误。new_block把两条语句串成一条链，步进挂在循环体末尾，这样continue的语义会略有偏差，教学项目可以接受，要严格的话得在continue跳转目标上做处理。node->init交由外层块语句先执行，等价于把初始化提到循环前面。

验证方法用差分测试最靠谱，同一批.c文件分别交给系统编译器和你的编译器，比较退出码：

for f in test/for_*.c; do ./cc "$f" > tmp.s && cc -o tmp tmp.s && ./tmp; got=$? cc -o ref "$f" && ./ref; want=$? [ "$got" = "$want" ] || echo "MISMATCH $f: $got != $want" done

改造时按这个顺序推：先加关键字，跑一个只含for关键字的用例确认词法不报错；再加解析分支，用print_ast看树形状对不对；最后跑代码生成，用差分脚本兜底。每一步都留一个能回退的提交，别一口气改完再调，否则出问题你分不清是词法、语法还是后端。

从那以后我每次给这类小编译器加特性，都强制先把测试用例和期望值写进去，再动代码，跑一遍差分脚本才允许自己提交。这套习惯救过我很多次，尤其是改表达式层的时候，人眼很难看出优先级哪里错了，机器一跑就现原形。希望帮到你。

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