伏羲-128：全中文“字义指令集”设计与工具链实现

1. 为什么做一套“字义指令集”

折腾了三个周末，终于把伏羲-128 从想法变成了能跑程序的工具链。简单说，伏羲-128 是一套全中文的“字义指令集”，128 条指令，每条指令的名字不再是 MOV、ADD、SUB 这种英文缩写，而是“取、存、加、减、与、或、跳、停”这类直接带有语义的汉字。更关键的是，这些汉字不是简单翻译过来的助记符，而是真正参与机器码编码的“字义码”。配套的汇编器 fuxi-as、模拟器 fuxi-vm 也都写完了，斐波那契、冒泡排序、素数筛已经能在上面跑通。

这个项目想解决的，是我在教朋友计算机组成原理时看到的真实痛点：很多人第一次接触汇编，第一反应不是“CPU 怎么工作”，而是“MOV 到底是什么单词”。英文缩写对中文母语者多了一道记忆映射。既然指令集只是约定好的二进制助记层，为什么不能直接用汉字？我花了三个周末把这个问题变成一套可运行的设计，也算给自己一个交代。这篇总结我不打算写成论文，而是把设计思路、编码格式、工具链实现和踩过的坑一起整理出来。如果你也对指令集设计、自制 CPU 或者中文编程感兴趣，伏羲-128 应该能给你提供一个足够完整的参考样本。

1.1 从英文助记符到中文字义的观察

所有现代指令集里，助记符承担的任务都一样：把赤裸裸的二进制操作码翻译成人能看懂的符号。x86 用 MOV，RISC-V 用 LD/ST，ARM 用 LDR/STR。问题在于“MOV”“LD”这类缩写必须经过一次记忆转换，中文使用者才能真正理解它是“把数据从一个地方搬到另一个地方”。我在早期尝试里也走过弯路：直接建一张翻译表，把所有英文助记符改成中文，比如 ADD 对应“加”，SUB 对应“减”。验证后发现这仍然是“翻译”，不是“字义设计”，因为机器码层面根本不知道“加”是什么，汇编器只是把“加”当成 ADD 的另一个代号。而且遇到 MOV 这种一词多义的助记符就会卡住：MOV 可以搬立即数、搬寄存器、搬内存，一个“搬”字根本说不清楚。

所以伏羲-128 放弃了“翻译”路线，改走“字义编码”路线。核心思路是：指令本身就应该是一个语义完整、一义一字的汉字节点。比如“取”表示“从指定地址加载到寄存器”，“存”表示“从寄存器写入指定地址”，“加”表示“寄存器之间或寄存器与立即数做加法”，“跳”表示“无条件改变 PC”。每一个字就是一个最小的语义单位，在汇编器里查表生成字义码，在模拟器里用字义码决定执行动作，在反汇编器里再查表还原回汉字。这样整条工具链都把“字义”当作一等公民，而不是给英文字母做美化。

1.2 目标用户和设计原则

伏羲-128 的目标用户非常明确：正在学计算机组成原理的本科生、想搞明白指令集是怎么工作的极客、以及想用中文做底层教学实验的老师。它不是用来挑战 x86 或 RISC-V 的，更多是做一个“看得懂的指令集”，把传统指令集内部那些藏起来的约定翻出来给人看。因此设计时刻意守了几条原则：

• 一义一字，一字一码。每个基础字只有一个含义，宁可用双字词组，也不用多义字。比如“与”在中文里有很多用法，但在伏羲-128 里只代表按位与。
• 字义码必须留在机器码里。这不是普通的汇编助记符翻译，机器码里有一个专门字段存汉字对应的编号，方便反汇编和调试器还原。
• 指令数量控制在 128，不求多，但求覆盖数据搬运、整数运算、位操作、跳转控制和系统控制这几类常见场景。
• 先用模拟器跑通，再用传统数字电路思路反推译码难度。一个设计如果模拟器里都绕来绕去，上硬件只会更痛苦。

1.3 “128”这个数字不是随便拍的

一开始我拍脑袋定了 256 条，但列到一半发现大量指令其实只是“同一操作的不同寻址模式”，比如“加”可以分为寄存器加立即数、加偏移、条件加等等。与其把每条都当独立指令，不如把“基础字”和“变体”分开。伏羲-128 的最后方案是：32 个基础字 × 4 种变体 = 128 条指令。32 正好是 5 位字义码的全部空间，4 种变体占 2 位，5 加 2 等于 7，也就是 2 的 7 次方，128。这样指令编码非常干净，也给后续扩展留下了清晰路径。当然 28 个基础字已经能覆盖常用操作，剩下的 4 个字义码位作为保留，将来加浮点、向量指令时可以无缝扩展，不用推翻整个格式。

这个设计对初学者也很友好：你不需要背 128 个毫不相关的助记符，只需要理解 28 个“字根”的含义，再记住每种字根有“普通、立即、条件、保留”四种变体，大概十几分钟就能掌握语法骨架。

2. 指令集的编码格式与语法定义

2.1 五大类字根和变体分配

我先按传统指令集的分类方式把 28 个基础字分成五组，每组内部的字根共享相近的位域特征。具体分配如下：

可能有人会问“比”到底是运算还是跳转？在伏羲-128 里“比”只负责比较两个值并设置条件标志位，真正的条件跳转由“跳”加上“条件变体”完成。比如“条件跳”的两个操作数是比较结果标志和跳转目标。这套设计的优点是译码逻辑非常对称，比较指令不需要关心跳转目标，跳转指令不需要关心数据通路。

变体码我用了 2 位，含义如下：

2.2 32 位定长指令里的“字义域”

每条伏羲-128 指令固定 32 位，比 16 位格式更宽裕，也更容易在模拟器里解析。位域定义如下：

这里最关键的字段是“字义域”，也就是第 27 到第 23 位。传统指令集里操作码是一堆无意义的二进制编号，比如 0x00 可能是 NOP，0x01 可能是 ADD；而伏羲-128 的操作码本身就是某个汉字的编号。汇编器在生成机器码时，会从“取=0x00”“存=0x01”“加=0x06”这样的字义索引表里查编号；反汇编器则用同样的表把编号翻译回汉字。由于字义码被固定编码在机器码中，哪怕机器码文件没有额外符号表，也能完整还原成中文汇编源代码，这是字义指令集和“英文助记符 + 调试符号”方案最大的不同。

在设计这个字义域时，我还考虑过一个更激进的方案：直接用汉字 Unicode 编码的低字节当作操作码。比如“取”的 Unicode 是 0x53D6，取低 8 位是 0xD6，作为操作码；“存”的 Unicode 是 0x5B58，低 8 位是 0x58。这个方案最直观，但很快被否定了，因为汉字成千上万，不同汉字低字节可能相同，会产生大量冲突。最终还是回到传统做法：用一张“字义索引表”给每个汉字分配一个 0 到 31 的编号，机器码只存编号，语义解释权交给工具链和文档。这张表只有 32 行，比查 Unicode 再映射要快得多，硬件译码时也只需要一张很小的查找表。

2.3 汇编语法：汉字助记符 + 熟悉的操作数

这里做个实际感受。比如计算 7 乘 6 加 5，我用 RISC-V 风格会写：

asm复制li r0, 7
li r1, 6
mul r2, r0, r1
li r3, 5
add r2, r2, r3

换成伏羲-128 的语法：

asm复制立 r0, #7
立 r1, #6
乘 r2, r0, r1
立 r3, #5
加 r2, r2, r3
停

有汇编基础的人一眼就能对上。唯一的差异是助记符换成了汉字，操作数部分我刻意保留了 r0、#imm、[基址+偏移] 这些约定，避免把符号层面的改动扩散到所有设计维度。内存访问也沿用了常见格式：

asm复制取 r0, [r1+4]    # r0 = MEM[r1+4]
存 [r1+4], r0    # MEM[r1+4] = r0

“取”的方向是“从内存取到寄存器”，“存”的方向是“把寄存器存入内存”。为了避免日后的二义性和初学者的困惑，汇编器会在源文件里检查这两个指令的操作数顺序，写反了直接报错，绝不静默。

伪指令目前只有三个：空 是空操作，延 是让模拟器暂停若干个时钟周期，立 是加载立即数。控制流用标签实现，例如从 1 加到 10 的循环：

asm复制立 r0, #0
立 r1, #10
循环:
加 r0, r0, r1
减 r1, r1, #1
比 r1, #0
条件跳 结束, 等
跳 循环
结束:
停

这里“条件跳 结束, 等”的第二个操作数提出了一个小问题，语法上我允许用中文条件字“等、不等、零、非零、负、正”来描述条件，避免再去背 EQ、NE、LT 这些英文缩写。汇编器在预处理阶段会把“条件跳”展开成对应的条件变体指令，并把中文条件字编码到谓词字段。伏羲-128 并不是把中文硬塞进一个原本属于英文的框架里，而是让条件、操作、目标都用中文语义表达，这点我在设计时体会很深。

3. 工具链的实现：从汇编到模拟执行

工具链一开始只用 Python 写原型，因为重点在验证指令集语义，而不是榨干运行性能。等语义稳定后再接触 C 或者 Verilog 也不迟。下面分享关键模块的实现思路，代码我不会贴完整版，但核心逻辑足够你自己复刻一个。

3.1 字义汇编器 fuxi-as：中文分词并不难

拿到一个中文汇编源文件后，第一步是清洗文本。我用 Python 的 open(..., encoding="utf-8-sig") 读取，直接吃掉 UTF-8 的 BOM；接着把全角逗号“，”和全角冒号“：”统一替换成半角，避免用户在中文输入法和英文输入法之间来回切换时踩坑。第二步是做词法切分，把每一行按空白和逗号拆成 token。这里的切分比英文汇编简单得多，因为中文助记符没有大小写、没有词形变化，token 就是“立”“r0”“#7”这样的短串。

核心映射表可以直接写在源码里：

python复制fuxi_op = {
    "取": 0x00, "存": 0x01, "读": 0x02, "写": 0x03,
    "传": 0x04, "立": 0x05,
    "加": 0x06, "减": 0x07, "乘": 0x08, "除": 0x09,
    "模": 0x0A, "比": 0x0B,
    "与": 0x0C, "或": 0x0D, "非": 0x0E, "异": 0x0F,
    "移": 0x10, "环": 0x11,
    "跳": 0x12, "呼": 0x13, "返": 0x14, "停": 0x15,
    "空": 0x16, "延": 0x17,
}

汇编一行指令时，我先根据助记符查表得到字义码，再看操作数里有几个 #，决定要不要把变体码置为“立即变体”。操作数的坑集中在“立”上，它只有一个目的寄存器和立即数，但立即数可以是 0 到 255 的短立即数，也可以是需要先用两条指令装载的长立即数。我最初图省事，只支持 8 位立即数，跑冒泡排序时数组元素超过 255 就得倒腾两次，后来我把 立 设计成同时接受 32 位立即数，工具链自动判断走“短立即数指令”还是“长立即数序列”，这个经验后面会再讲。

3.2 模拟器 fuxi-vm：解释执行一个“汉字 CPU”

模拟器是验证指令集语义是否自洽的关键工具。fuxi-vm 的模型很传统：32 个 32 位通用寄存器 r0-r31、1MB 字节寻址内存、一个 PC 寄存器、若干条件标志位。取指阶段从内存读 4 字节，按小端序拼成整数；译码阶段分别取出类型域、字义码、变体码和三个寄存器字段；执行阶段则是一张巨大的分发表。

python复制while not halted:
    inst = load32(pc)
    typ = (inst >> 28) & 0xF
    op  = (inst >> 23) & 0x1F
    var = (inst >> 21) & 0x3
    rd  = (inst >> 10) & 0x1F
    rs1 = (inst >> 5)  & 0x1F
    rs2 = inst & 0x1F
    pc += 4

    if typ == 0 and op == fuxi_op["立"]:
        reg[rd] = sign_extend(rs2)   # 简化示意
    elif typ == 1 and op == fuxi_op["加"]:
        reg[rd] = reg[rs1] + reg[rs2]
    # ...

实际的执行函数比示意复杂，因为“条件变体”需要在执行前检查条件标志；“取”“存”要处理字节序和对齐错误；“移”还需要判断是逻辑右移还是算术右移。不过整个模拟器只有不到五百行，写起来比预想中顺利。真正花时间的不是解释器本身，而是把指令集语义描述得足够精确，比如“比 r1, #0”到底比较的是 r1 与立即数 0，还是 r1 与寄存器 0？我在汇编器里做了严格约定：出现 # 就走立即数变体，寄存器名裸写就走普通变体，两条路径对应不同的变体码，绝不含糊。

3.3 反汇编器和调试体验

光有汇编器和模拟器还不够，跑程序后总得知道“我到底执行了什么”。反汇编器 fuxi-objdump 的核心逻辑就是把机器码反向翻译回汉字。因为指令格式固定，反汇编不需要任何符号表，直接按位提取字义码和变体码，再查表还原助记符，操作数则根据变体码区分立即数或寄存器。运行 fuxi-objdump 后，得到的输出长这样：

text复制0x00000000: 立 r0, #7
0x00000004: 立 r1, #6
0x00000008: 乘 r2, r0, r1
0x0000000C: 立 r3, #5
0x00000010: 加 r2, r2, r3
0x00000014: 停

调试器我加了个很朴素的功能：可以在中文指令上打断点。不是真的用汉字做地址，而是支持你写 break 0x00000008，同时输出当前 PC 处的反汇编结果。调试时最常用的操作是单步执行和打印寄存器快照。我会在每步之后输出一行类似 PC=0x14 r0=7 r1=6 r2=35 的信息，方便对比寄存器变化。这套“汇编器-模拟器-反汇编器”的最小闭环，让我每次改完指令集语义都能在一分钟内完成全流程验证。

4. 实际运行效果与踩坑记录

4.1 三个经典例程跑通

最先跑的是 1 到 10 求和，因为逻辑最简单，验证完基础算术、跳转和比较之后，再上稍微复杂一点的程序。然后是斐波那契数列，用递归写法比较直观，主要验证“呼”“返”这套函数调用机制。递归函数需要栈帧，模拟器里没有专门栈指针寄存器，我直接用 r31 当栈指针，“呼”的时候把返回地址压入内存，“返”的时候弹回 PC。最后做的是冒泡排序，把 [5,2,8,1,9] 排成 [1,2,5,8,9]，这一步把访存指令、比较指令和多重循环结合到一起，算是给指令集做了一次完整压力测试。

个中体会是：指令集设计得再花哨，能跑通这几个经典程序才算真的可用。我在跑斐波那契时发现递归调用栈经常因为忘记保存 r31 而互相覆盖，后来在指令集层面增加了一条“传”指令来保存恢复寄存器，才彻底解决。这说明指令集设计不是纸上谈兵，必须靠实际程序反推修正。

4.2 高频问题速查表

我把开发过程中被问得最多的几个问题整理成了一张表，也是自己在不同阶段踩过的坑。

这些问题的共同教训是：中文助记符不会天然屏蔽掉底层指令集的复杂度，设计时反而要更严格地定义每个字段的语义，否则调试起来满屏汉字不一定比满屏英文更好懂。

4.3 性能与实用价值的实话实说

有一说一，伏羲-128 的性能和工程价值都很有限。Python 模拟器解释一行指令大概需要执行几十次 Python 运算，跑个一万次循环已经能感觉到卡顿。要把这套指令集送上硬件，至少得写一个五级流水线处理器，字义码译码部分和传统译码没有本质区别，都是靠组合逻辑查表。性能瓶颈从来不在助记符用中文还是英文，而在指令编码本身是否规整、流水线冲突是否好处理。伏羲-128 的 32 位定长格式、5 位字义码、2 位变体码，其实对硬件译码相当友好，如果将来真做 CPU，译码器可以用两张小查找表完成，延迟不会因为汉字而显著变大。

更实际的价值在教学和思维实验。“字义指令集”证明了一件事：指令集底层的语义不依赖英语，汇编器和模拟器完全可以理解中文语义。对正在学体系结构的同学来说，自己写一个 128 条指令的小工具链，比单纯看教材上“PC、IR、ALU”的定义要直观得多；这也是伏羲-128 存在的最大意义。

5. 后续扩展方向与个人体会

5.1 还能往哪些方向扩展

这套东西目前只覆盖整数和基础控制流，扩展空间还很大。最容易的一步是把保留的字义码用起来，比如增加“浮”开头的浮点指令族，用 浮加、浮乘、浮比 之类的字根对应 IEEE 754 运算；或者增加“向量”指令族，支持 载入向量、存储向量、向量加 这类批处理操作。还有一条路是做一个真正能用键盘输入的集成开发环境，给伏羲-128 的汇编源文件做语法高亮和智能提示，编辑中文助记符的时候自动补全操作数模板。如果精力允许，还可以把模拟器移植到 WebAssembly 上，直接在浏览器里跑中文汇编程序，这样教学演示的传播成本会低很多。

5.2 关于字义指令集，我最后想说的几句话

经历这 3 个周末，我最大的体会是指令集设计真正的难点不是“把助记符翻译成中文”，而是“语义到底怎么切分才干净”。一开始我想把“返回”“跳回”“退出”统统扔给一个“回”字，结果连自己都分不清程序在调用还是在循环。后来我把每个字义码当成一个独立的 API 来设计，一义一字，宁可多造几个基础字，也不做一石二鸟的模糊指令，整个工具链才稳定下来。

另一个感受是，用中文做底层设计并没有想象中困难，真正麻烦的是处理中文文本的编码和输入法习惯。但是一旦把 UTF-8、BOM、全角符号这些坑填平，剩下的逻辑和传统指令集没有区别。伏羲-128 确实不能取代任何成熟指令集，它更像一次思维实验：如果当初计算机产业从中文世界蓬勃生长，指令集会不会长成另一个样子？至少从我的实践看，这个设想完全可行。

如果你也想做一套属于自己的指令集，我的建议是先别急着写代码，拿一张纸把字根表画出来，把每条指令的输入、输出、副作用写清楚，再动手写汇编器。我这个版本因为在设计中途频繁改字义码表，导致反汇编器跟着返工了好几次，教训相当深刻。但只要熬过这个阶段，看着自己定义的“字义指令集”把一段中文汇编跑出正确结果，那种满足感确实值得回味。