对于大多数工程师而言， Forth 这门诞生于上世纪七十年代的语言总是带着一层神秘色彩。它没有庞大的运行时、没有复杂的抽象语法树，甚至没有一个独立的「编译器」—— 所有的编译与执行都在同一个极简框架内完成。然而正是这种看似原始的设计，却蕴含着现代语言运行时中难得一见的工程简洁性与执行效率。本文将从一个最小可运行的 Forth 解释器出发，重点剖析直接线程解释（Direct Threaded Code, DTC）的内部工作机制，并给出词法分析环节的工程实现参数。
直接线程解释的核心模型
理解 Forth 的执行模型，是从零实现解释器的第一步。与传统编译型语言将源代码翻译为机器码后再执行不同， Forth 采用了一种介于解释与编译之间的中间形态：线程代码（Threaded Code）。在这种模型下，每一个词（Word，相当于其他语言中的函数或指令）并不直接包含机器指令序列，而是包含指向其他词代码字段的指针序列。解释器通过遍历这个指针序列，逐个调用对应的执行代码，从而完成整个程序的运行。
在直接线程解释中，每个词的参数区域直接存储的是代码地址（CFA，Code Field Address），解释器的核心职责就是不断地取出下一个代码地址并跳转执行。这个过程由一个极短的内部解释器完成，通常称为 NEXT。以 C 语言伪代码描述，直接线程解释的 NEXT 大致如下：
void NEXT(void) {
Cell cfa = *IP++; // 从线程中取出下一个 CFA，并推进指令指针
goto *(void **)cfa; // 跳转到该地址对应的代码
}
这里的 IP 是指令指针（Instruction Pointer），指向当前正在解释的线程；RP 是返回栈指针，用于保存调用点；Cell 是 Forth 中最基本的数据单元，通常是一个机器字长。在实际实现中，为了追求极致的执行效率，这个 NEXT 通常会被内联为一个或几条汇编指令，而非一个完整的函数调用。
整个系统的运行可以概括为三个核心栈的协作：数据栈（Data Stack）用于普通计算、返回栈（Return Stack）用于保存调用现场的 IP、以及一个词典（Dictionary）用于存储所有已定义词的元信息与执行代码。这三个组件构成了 Forth 解释器的骨架。
词典结构的工程细节
词典是 Forth 中最核心的数据结构，它既是命名空间，也是代码仓库。一个典型的词典条目在内存中的布局如下：
+------------------+
| link (prev word) | <-- 指向上一条词典目的 link 指针
+------------------+
| flags/len | <-- 标志位与名字长度打包在一起
+------------------+
| name chars... | <-- 可变长度的词名
+------------------+ (对齐到下一个单元边界)
CFA -> | code field | <-- 代码字段地址，指向执行逻辑
+------------------+
PFA -> | parameter field | <-- 参数字段：词的实现数据
+------------------+
对于原始词（Primitive，由机器码或 C 代码直接实现），代码字段直接指向该词的实际执行逻辑；对于冒号定义（Colon Definition，由其他词组合而成），代码字段通常指向一个公共的入口例程 DOCOL，而参数字段则存储由若干 CFA 组成的线程。
以一个具体的词定义为例：
: SQUARE DUP * ;
在直接线程解释下，它的内存布局大致如下：
CFA(SQUARE): &DOCOL
PFA(SQUARE):
&DUP
&MUL
&EXIT
这里的 &DUP、&MUL、&EXIT 都是指向各自代码字段的地址。当解释器执行 SQUARE 时，首先跳转到 DOCOL，DOCOL 负责将当前的 IP 压入返回栈，然后让 IP 指向 SQUARE 的参数区域，随后 NEXT 依次遍历执行 DUP、MUL，最后遇到 EXIT 时从返回栈恢复之前的 IP，继续执行调用点的后续逻辑。
DOCOL 与 EXIT 的实现机制
DOCOL 是连接词与词之间的桥梁，它的核心职责是建立新的执行上下文。每次执行一个冒号定义时，DOCOL 需要完成三件事：保存当前 IP 到返回栈、加载新词的参数区域到 IP、启动对新线程的解释。其伪代码实现为：
void DOCOL(void) {
*--RP = IP; // 将调用者的 IP 压入返回栈
IP = (Cell *)PFA(this_word); // IP 指向当前词的语气区域
NEXT(); // 开始解释新线程
}
需要特别注意的是，在直接线程解释中，DOCOL 本身也是一个「词」，它有自己的代码字段地址。当解释器取到 &DOCOL 这个 CFA 时，正是通过 NEXT 的跳转机制进入 DOCOL 的执行逻辑，从而完成上下文的切换。
与 DOCOL 相对应的是 EXIT，它负责在词定义执行完毕后返回调用点。EXIT 的实现同样简洁：
void EXIT(void) {
IP = *RP++; // 从返回栈弹出之前保存的 IP
NEXT(); // 继续执行调用者的线程
}
在实际编译时，; 这个词（即编译 EXIT）会被插入到每个冒号定义的末尾，确保执行完毕后能够正确返回。
literal 数据的处理：LIT 机制
除了执行预定义的词， Forth 还需要处理字面量数据（Literals），比如在代码中直接出现的数字。线程代码并不能直接在参数区域存储普通数据，因为参数区域本应存放的是 CFA。为此， Forth 引入了一个特殊的原始词 LIT（Literal），它的职责是：从线程中读取下一个单元作为数据而非代码地址，并将其压入数据栈。
LIT 的工作流程如下：假设有如下 Forth 代码片段在解释执行：
42 .
编译后的线程大致是：
&LIT
42
&.
&EXIT
当解释器执行到 &LIT 时，LIT 的代码会执行以下操作：
void LIT(void) {
push(*IP++); // 取出线程中的下一个单元作为数据，压入数据栈
NEXT();
}
这样，数字 42 被正确地识别为数据而非指令，随后 &. 将其弹出并打印。在编译模式下，解释器遇到数字时会自动生成 &LIT 与数字本身的序列，确保运行时能够正确处理字面量。
解释循环与编译模式
在最外层， Forth 解释器是一个不断循环的读取 - 执行过程。解释器需要处理两种状态：解释模式（INTERPRET）与编译模式（COMPILE）。在解释模式下，查找到的词会立即执行；在编译模式下，查找到的词会被追加到当前正在定义的线程中，而不是立即执行。某些特殊的词（如 IF、LOOP 以及前文提到的 ;）具有「立即执行」属性（Immediate），即使在编译模式下也会被立即触发。
一个简化的解释循环可以用以下伪代码描述：
for (;;) {
char *token = parse_word(); // 从输入中读取下一个词
Word *w = dictionary_lookup(token); // 在词典中查找
if (w) {
if (state == INTERPRET || w->immediate) {
execute(w->cfa); // 执行该词
} else {
*here++ = w->cfa; // 将 CFA 编译到当前线程
}
} else if (parse_number(token, &n)) { // 尝试解析为数字
if (state == INTERPRET) {
push(n); // 解释模式：直接压栈
} else {
*here++ = &LIT; // 编译模式：生成 LIT 序列
*here++ = n;
}
} else {
error("unknown word: %s", token);
}
}
其中 parse_word() 负责从输入缓冲区中提取下一个空白符分隔的词，这正是词法分析的入口。词法分析的质量直接影响后续所有阶段的正确性。
词法分析：最小可行实现
Forth 的词法分析极为简单 —— 它只需要按空白符（空格、换行、制表符）分割输入流，返回连续的字符序列即可。然而即便如此，仍然有一些工程细节值得注意。
首先是输入缓冲区的管理。一个健壮的解释器通常会维护一个输入缓冲区，并提供 REFILL 词来尝试填充缓冲区。当缓冲区为空时，REFILL 会尝试从标准输入或其他输入源读取新行。缓冲区的大小通常选择为 80 字符或 128 字节，与终端行宽相近。
其次是词名的解析规则。Forth 约定词名由可见字符组成（通常排除空格和换行），且不区分大小写 —— 这意味着 DUP、Dup、dup 指向同一个词。在实现字典查找时，通常会在比较前将词名统一转换为小写或大写。
一个最小可用的词法分析函数可以这样实现：
char *parse_word(void) {
char *p = input_ptr;
while (*p == ' ' || *p == '\t' || *p == '\n') p++; // 跳过空白
char *start = p;
while (*p != ' ' && *p != '\t' && *p != '\n' && *p != '\0') p++;
*p = '\0'; // 临时以空字符结尾
input_ptr = p + 1; // 下次从下一个字符开始
return start;
}
这个实现假设输入缓冲区已经准备好，并且通过临时修改缓冲区内容来标记词的边界。虽然不够优雅，但足以支撑一个最小解释器的运行。
工程实践参数与阈值
在从原型走向生产级实现时，以下几个参数和阈值值得特别关注。
关于字典的初始大小，通常建议预分配 8KB 到 64KB 的空间，具体取决于目标平台的资源约束。对于嵌入式场景，16KB 是一个合理的起点。字典采用链表结构组织，查找时间复杂度为 O (n)，但在实际使用中 Forth 程序的字典规模通常很小，线性查找的开销可以接受。
返回栈和数据栈的大小需要根据实际计算深度来设定。对于嵌入式场景，典型配置为 64 到 256 个单元（Cell）；对于桌面级解释器，可以动态扩展或设定为 1024 以上。这些栈通常实现为固定大小的数组，并在溢出时触发运行时错误。
在解释器外层循环中，每次读取词后都需要进行字典查找与可能的数字解析。对于追求性能的实现，可以使用哈希表替代链表来加速字典查找，但这会显著增加实现复杂度。对于一个最小可用的解释器，链表加线性查找已经足够。
另一个重要的工程决策是错误处理策略。Forth 的传统做法是「 abort 」—— 遇到未定义的词时直接放弃当前解释并返回顶层交互模式。现代实现通常会提供更友好的错误信息，包括词名、出现位置等调试信息。
小结
从零实现一个最小 Forth 解释器的核心，在于理解直接线程解释的执行模型与词典的物理布局。NEXT 的几条指令完成了整个运行时的核心调度；DOCOL 与 EXIT 负责上下文的建立与恢复；LIT 机制让字面量数据得以嵌入线程；而外层的解释循环则通过简单的词法分析与状态切换，实现了从交互输入到可执行线程的完整转换。
这些机制看似原始，却构成了 Forth 独特的设计哲学：让语言本身尽可能薄地将权力让渡给程序员。对于任何对解释器构建、运行时设计或底层系统编程感兴趣的工程师而言，实现一个最小 Forth 解释器都是一次不可多得的实践机会。
资料来源：Forth 线程代码实现的技术细节参考了 Compilers and Languages 专题论文及 GitHub 上多个开源 Forth 实现的源码结构。