从 calc 到 diksam：自制编程语言源码编译与避坑指南

简介《自制编程语言》相关资料1以PDF形式梳理编程语言从设计、实现到使用的核心知识面向正在学习编译原理、尝试开发小型语言或希望理解编译器与解释器工作流程的开发者也可作为课程实践与项目入门的参考资料。压缩包内仅含1个PDF文件大小约2.38MB篇幅集中便于按主题阅读和检索。已有870人浏览学习。材料围绕语言设计原则、实现工具、运行环境和跨平台开发展开涉及yacc/lex、bison/flex、MinGW等工具链并引入Crowbar与Diksam两个自制语言实现案例帮助读者把词法语法分析、编译器与解释器构建以及Linux、Windows下的环境差异串联起来。对于想了解一门小语言如何从语法规则走向可执行程序、如何选择构建工具并管理运行时资源的读者这份资料能提供较清晰的案例参照与知识索引。1. 从一份 2013 年的 ZIP 说起这套资料能让你把“自制编程语言”跑起来手里这份资料最直观的样子是两个 ZIP一个标着 20131212一个标着 20091228解压后是四个目录群calc、mycalc、llparser、crowbar 和 diksam。它不是讲编程语言理论的讲义而是一份能编译、能运行、能改的源码合集覆盖了从“用 yacc/lex 拼一个四则运算器”到“手写词法器 递归下降”再到“带 GC 的动态类型脚本语言解释器”和“带类的静态类型语言编译器”这条完整路径。适合两类人一类是想把编译原理课本里的 LL(1)、LR、符号表、闭包这些东西落到 C 代码里的人另一类是接手了老式 C 工程、被 Makefile 和 bison/flex 的报错卡住、想找一份能对拍的样板的人。它不轻Windows 下要先把 MinGW、bison、flex、oniguruma 这一串装齐装的过程本身就是第一道门槛。2. 先理清目录calc、llparser、crowbar、diksam 四条主线怎么选解压后不要急着敲 make先把四个目录群的分工看明白。它们不是四个并列的 demo而是难度递进的四个阶段选错入口会白白耗掉半天时间。下面这张表按“输入文件类型 / 构建入口 / 外部依赖 / 学习目标”四列对齐先对号入座再动手。目录群语言形态构建入口关键依赖主要解决什么calc中缀表达式求值直接 gcc 或 make无语法树、求值顺序mycalc / mycalc_exyacc/lex 驱动的计算器makebison、flex生成器怎么把 .y/.l 变成 Cllparser / llparser_ex手写词法 递归下降make无不依赖生成器的完整前端crowbar_book_0_x动态类型脚本语言解释器make.sh / make.batbison、flex、oniguruma解释器骨架、GC、字符串池diksam_book_0_x静态类型、带类的编译器0_1/0_2 进 compiler0_3/0_4 进 mainbison、flex、oniguruma类型检查、中间代码生成2.1 calc 到 mycalc先看清生成器的输入和输出calc 是最裸的起点。它把表达式解析和求值写在一起没有词法层没有符号表适合用来确认“我这台机器上 gcc 能不能把一份多文件 C 工程链起来”。真正有价值的是 mycalc它把词法规则放进 .l 文件、语法规则放进 .y 文件由 flex 生成 lex.yy.c由 bison 生成 y.tab.c 和 y.tab.h再由 gcc 把这三份 C 和手写的主程序链成可执行文件。这一步的关键认知是.l 和 .y 不是源码是生成器的输入规格。很多新手把 .l 文件当成 C 文件直接 gcc报“找不到 y.tab.h”就是这个原因——头文件是 bison 跑完才产生的顺序反了。正确的顺序永远是先 bison 后 flex 再 gcc因为 flex 生成的 C 里会 #include “y.tab.h”而这份头文件由 bison 产出。mycalc_ex 是同一份东西的改进版本两版对照着看能看出作者在处理优先级、错误恢复上的取舍差别这种差别在教科书里通常被一笔带过。2.2 llparser不依赖生成器的那条路llparser 和 llparser_ex 是这套资料里最容易被低估的部分。它不调用 bison词法分析和语法分析全部手写语法分析采用递归下降。对打算自己动手写一门小语言的人来说这条路比 yacc/lex 更值得先走一遍因为你必须自己想清楚“当前读到哪个 token”“出错时怎么恢复”“怎么把 token 流喂给下一层”。它的结构通常是一个词法分析函数按行读入、切 token、填进缓冲区一组语法函数按非终结符一一对应遇到终结符就比对遇到非终结符就递归下降。这种写法没有生成器的魔法出错位置和调用栈一目了然缺点是改语法要同时改函数规模一大就难维护——这也正好解释了为什么后面的 crowbar 和 diksam 又回到了 bison/flex。llparser_ex 是在 llparser 基础上的修正版。这一版里有一个很典型的 C 语言坑词法缓冲区用了static char *st_line声明但没分配内存就直接传给 fgets程序在 Linux 上可能侥幸不崩在别的平台上直接段错误。修复方式是把指针换成定长数组。这个细节值得单独拎出来看因为它代表了一整类“能编过但跑不对”的问题。2.3 crowbar 与 diksam从解释器到编译器的分水岭crowbar 是动态类型脚本语言走的是“解析成语法树 → 直接遍历执行”的解释器路线。它分 0_1 到 0_4 四个版本按书的章节推进其中 0_2 开始引入 GC垃圾回收后面的版本继续补类型系统和运行时功能。diksam 是静态类型语言带类走的是“解析 → 类型检查 → 生成中间代码 → 虚拟机执行”的编译器路线同样分 0_1 到 0_4。两者最实际的差别在构建目录上diksam 的 0_1 和 0_2 要在 compiler 子目录里执行 make/gmake0_3 和 0_4 的入口挪到了 main 子目录。这个变化不是随意的它对应着工程结构的重构——早期把编译器和虚拟机塞在一起后期拆开了。如果你照着 0_1 的经验去 0_4 目录里直接 make会得到“没有目标、找不到 Makefile”这类看起来莫名其妙的报错原因只是站错了目录。crowbar 则相对统一四个版本的入口都更靠外用 make.shLinux或 make.batWindows驱动。3. 搭工具链MinGW、bison、flex 与 oniguruma 的安装顺序Windows 上的坑有八成集中在这一步而且很多报错看起来和工具链毫无关系。装的时候按“编译器 → 生成器 → 正则库”的顺序走每一步都验证一下比一口气装完再排查要省时间。Linux 下反而简单gcc、bison、flex 一般发行版仓库里就有真正需要手动编的只有 oniguruma。3.1 MinGW 装什么为什么 make 会变成 gmakeMinGW 走的是在线安装器路线下载安装器指定安装目录进到包管理界面后必须手动勾选。至少要勾 mingw32-base提供 gcc、binutils 这一套和 make。默认什么都不勾装完只有一个空壳这是第一个高频翻车点——目录建好了bin 里没有 gcc。装完之后Windows 上还会遇到 make 名字的问题。MinGW 提供的可执行文件叫 mingw32-make.exe不叫 make.exe。而工程里的 Makefile 和脚本里写的是 make 或 gmake。常见做法有两种把 mingw32-make.exe 复制一份改名成 gmake.exe 放回 bin 目录或者改名叫 make.exe。前者更稳妥因为某些 Makefile 里显式调用了 gmake改名成 make 之后那些规则仍然会失败。验证是否装好直接开 cmd 敲路径全称别依赖 PATHD:\MinGW\bin\mingw32-make.exe --version D:\MinGW\bin\gcc.exe --version第一行输出 GNU Make 的版本信息、第二行输出 gcc 版本说明基础环境通了。这里用绝对路径是有意的PATH 没配好之前敲 make 只会得到“不是内部或外部命令”你会误以为是没装成功其实只是没找到。3.2 bison 和 flex 必须装在无空格路径里这是整套资料里最值得记的一条血泪经验。bison 在运行时会去自己的安装目录下找 m4sugar.m4 等宏文件找的方式是把路径拼成命令行传给 m4。如果 bison 装在C:\Program Files (x86)\GnuWin32\这种带空格的路径下m4 收到参数时会把路径按空格切开于是报出一串很吓人的错误m4: cannot open Files: No such file or directory m4: cannot open (x86)\GnuWin32\Bison/share/bison: No such file or directory m4: cannot open D:\Program: No such file or directory看错误内容像是在说文件不存在实际是路径被空格肢解了。解决办法只有一条把 bison 和 flex 装到不带空格的目录比如D:\GnuWin32\。装完把它们的 bin 目录加进 PATH验证bison --version flex --version m4 --version三条都要能出版本号。m4 容易被漏掉它是 bison 的依赖很多 GnuWin32 的 bison 安装包不自带需要单独装。少这一条bison 会以更难懂的方式失败。3.3 onigurumaLinux 三行命令Windows 要手动补 ranlibcrowbar 和 diksam 的正则表达式功能依赖 oniguruma 这个 C 库。资料里用的是 5.9.4 版本源码包解压后标准三步tar -xvf onig-5.9.4.tar.gz cd onig-5.9.4 ./configure make make install./configure负责探测系统环境并生成 Makefilemake编译出 libonig.a 静态库和 libonig.so 动态库make install把头文件和库拷到系统目录。Linux 下通常一路畅通最多在前面加个 sudo。Windows 下用 MinGW 编译时前三步都能过make install会翻车libtool: install: ranlib /usr/local/lib/libonig.a D:\MinGW\bin\ranlib.exe: /usr/local/lib/libonig.a: No such file Makefile:415: recipe for target install-libLTLIBRARIES failed原因是 configure 阶段探测到的安装前缀是/usr/local而 MinGW 环境下这个路径并不真实存在或者不归 Windows 管于是 ranlib 找不到刚装过去的库文件。绕开的办法是不走 make install手动把编译产物放到位cd .libs ranlib libonig.a cp libonig.a /d/MinGW/lib/ cp ../oniguruma.h /d/MinGW/include/ranlib的作用是给静态库生成符号索引缺少这一步链接时会报 undefined reference即使库文件确实在。拷完之后在工程里加-lonig就能链上。这一步我一般会顺手把 oniguruma.h 也复制过去否则编译阶段就会先卡在no such file。4. 编译 Crowbar 与 Diksammake、gmake 与目录切换工具链齐了之后编译本身反而快麻烦的是记住每个版本该在哪个目录敲哪条命令。这一章把四个 crowbar 版本和四个 diksam 版本的构建路径逐一走一遍顺带说清楚编译成功之后怎么验证。4.1 crowbar 的四个版本入口在外层命令是 gmakecrowbar_book_0_1 到 0_4 的结构相对一致外层目录下有 make.shLinux和 make.batWindows。Windows 下不要直接双击 bat先开 cmd 切到目录cd /d D:\work\crowbar_book_0_1 D:\MinGW\bin\mingw32-make.exe如果你已经把 mingw32-make.exe 复制成 gmake.exe这条命令等价于gmake。编译过程会依次跑 bison、flex、gcc输出大概是这样一串bison --yacc -dv crowbar.y flex crowbar.l gcc -c -g lex.yy.c gcc -c -g y.tab.c gcc -c -g -Wall -Wswitch-enum -ansi -pedantic -DDEBUG main.c ...这里有几个参数值得留意。-Wall -Wswitch-enum -ansi -pedantic是一组偏严格的告警选项-ansi意味着按 C89 标准编译-pedantic会把非标准扩展都报出来。这套组合在老代码上跑出现警告是常态只要不是 error 就不必慌。-DDEBUG打开调试宏运行时会多打印一些内部状态读源码阶段建议保留。-dv是 bison 的调试选项会额外生成 crowbar.output 文件里面是完整的语法状态机描述。想搞清楚某个语法冲突到底出在哪条产生式看这个文件比看 .y 源码快得多。4.2 diksam 的目录切换0_1/0_2 在 compiler0_3/0_4 在 maindiksam 的构建入口位置随版本变化这是最容易踩空的地方。0_1 和 0_2 需要先进 compiler 子目录cd /d D:\work\diksam_book_0_1\compiler D:\MinGW\bin\mingw32-make.exe0_3 和 0_4 则要进 main 子目录cd /d D:\work\diksam_book_0_3\main D:\MinGW\bin\mingw32-make.exe如果你在 0_3 的根目录直接敲 make会得到gmake: *** No targets specified and no makefile found. Stop.这条报错的意思是“当前目录没有 Makefile”不是环境坏了。判断方法很土但有效进目录先dir看一眼有没有 Makefile没有就往下找一层。工程重构之后目录变了、构建脚本却没跟着改这类情况在真实项目里也常见把这套资料当练习材料正好。4.3 编译产物验证跑通第一个脚本才算成功编译出 exe 不代表能用必须跑一个脚本验证。crowbar 目录下一般自带 test 子目录里面是 .crb 脚本./crowbar test/test.crbLinux 下输出正常结果就说明解释器通了。Windows 下如果报错指向某个字符位置比如“第 5 行非法字符 0x0d”那不是语法错误是换行符问题。0x0d 是 CR说明脚本文件是 CRLF 换行而词法分析器只认 LF。Git 在 Windows 上默认会把文本文件转成 CRLFclone 下来直接跑就会撞上。处理方式二选一dos2unix test/test.crb或者在 git 配置里关掉自动转换git config --global core.autocrlf falsediksam 的验证类似编译出可执行文件后跑一个最小脚本确认类型检查和执行都走通。这一步别省因为 diksam 带类型系统语法对但类型不对的脚本会在编译期被拦下来正好用来验证你做出来的到底是解释器还是编译器。5. 避坑排查五条来自真实报错的记录这一章的五条都来自这套资料在实际环境里跑出来的报错按“现象 → 原因 → 解决”写遇到同款直接对号入座不用重新推一遍。5.1 报 y.tab.c / y.tab.h 找不到现象gcc 报y.tab.c: No such file or directory同时 flex 生成的 C 文件里报y.tab.h: No such file or directory。原因构建顺序被打乱了。y.tab.c 和 y.tab.h 都是 bison 的产物如果 bison 因为路径或参数问题失败后面的 flex 和 gcc 仍然会继续跑尤其是手写 batch 脚本时于是报出的是“文件不存在”真正的问题被藏在前面几行。解决单独跑一次 bison把它的报错看清楚。bison --yacc -dv crowbar.y跑完检查目录里有没有 y.tab.c、y.tab.h、crowbar.output 三个文件。少任何一个问题都在 bison 这一环跟 gcc 无关。5.2 bison 报 CreateProcess failed现象process_begin: CreateProcess(NULL, bison --yacc -dv crowbar.y, ...) failed后面跟着一串乱码最后是 Makefile 里某条规则 Error 2。原因make 在 PATH 里找不到 bison。注意它找的不是“bison 装没装”而是“当前 shell 的 PATH 里有没有 bison.exe”。装到 D 盘但没加 PATH一样报这个。解决把 bison 的 bin 目录加进系统 PATH重开一个 cmd 窗口让环境变量生效再where bison确认能找到。已经开着的窗口不会自动刷新 PATH这一点经常被忽略。5.3 链接阶段报 cannot find -lmsvcp60现象在 Linux 下编译 crowbar_book_0_4链接时报/usr/bin/ld: cannot find -lmsvcp60。原因工程里某处硬编码了 Windows 上的 C 运行库。libmsvcp60 是 Windows 平台的库Linux 上根本没有对应的 .so链接器自然找不到。解决在 Makefile 或链接脚本里把-lmsvcp60去掉。这个库在绝大多数纯 C 工程里并不需要属于历史遗留。改之前建议先备份 Makefile因为四个版本之间可能有共用脚本。5.4 运行时崩溃问题在未初始化的字符指针现象llparser_ex 编译通过运行到读入阶段直接段错误没有任何提示。原因词法分析器里用了static char *st_line;这样的声明指针没有分配内存就传给 fgets。fgets 会往这个野指针指向的地址写数据行为未定义——有时不崩有时崩在完全无关的位置。解决把指针改成定长数组char buf[1024]; while (fgets(buf, sizeof(buf), stdin) ! NULL) { parse_line(buf); }顺便把LINE_BUF_SIZE这个宏统一成sizeof(buf)的写法避免以后改长度时漏改一处。这类“编译通过但运行时炸”的问题在 C 工程里占比很高读别人代码时看到裸指针配 fgets 就该提高警惕。5.5 Cygwin 编出来的 exe 离不开 cygwin.dll现象用 Cygwin 的 gcc 编译 crowbar拿到另一台没装 Cygwin 的机器上运行报缺少 cygwin.dll。原因Cygwin 提供的是 POSIX 兼容层编译出来的程序依赖 cygwin1.dll 这个运行时本质上是“Windows 上的类 Unix 环境”不是原生 Windows 程序。解决要么目标机器也装 Cygwin要么改用 MinGW 编译。MinGW 直接调用 Windows API产物是原生 exe不依赖额外 DLL。这套资料里的 make.sh 和 make.bat 是两套脚本别混用——用 Cygwin 的环境跑 MinGW 的脚本路径风格对不上会冒出一堆找不到文件的错误。6. 增量对比法把 crowbar 0.1 到 0.4 读成一条进化链四个版本的源码摊在一起逐个读效率很低读到后面会忘了前面。我一般用目录 diff 的方式先看“新增了什么文件”再进到新增文件里看实现。这比通读整棵树快得多也更容易看出设计的演进逻辑。# 两个版本之间只列出文件名差异不比对内容 diff -rq crowbar_book_0_1 crowbar_book_0_2 # 只看 Makefile 的变化构建结构变了通常意味着模块被拆了 diff -u crowbar_book_0_1/Makefile crowbar_book_0_2/Makefile # 只比对某一类源文件 diff -u crowbar_book_0_2/create.c crowbar_book_0_3/create.c-rq递归比对但只输出“哪些文件不同、哪些只在一侧存在”适合第一遍摸清范围-u输出带上下文的统一 diff适合细看单个文件。跑完第一遍之后对着“只在 0_2 存在”的文件列一个清单这些通常就是新功能的载体。版本之间的功能落点可以这样对照版本跨度重点看什么预期能看到的变化0_1 → 0_2create.c、execute.c、新增加的内存管理文件引入 GC对象分配路径改变0_2 → 0_3符号表相关文件、语法文件作用域与变量查找逻辑扩展0_3 → 0_4运行时错误处理、字符串池错误信息带行号字符串去重这套方法的真正价值不在 crowbar 本身。接手任何一份“有多个历史版本”的老工程时都可以照这个路子先跑一遍 diff把变更范围框出来再去读核心文件。我印象最深的一次是直接在根目录扫了一遍所有 .c 文件花了整个下午最后发现关键改动其实只集中在三个文件里。从那以后我每次拿到多版本源码都强制先跑一遍 diff -rq把范围缩小再动手读者如果也在啃这类资料建议把这个习惯固定下来。希望帮到你。本文还有配套的精品资源点击获取