ARM 上的 Fun：只差一层机器码

# ARM 上的 Fun：只差一层机器码

有人把 Fun 搬到一台 ARM 机器上跑。能跑，而且除了「到机器码」这一层，别的地方和 x64 几乎没差别。这篇就说说那一层为什么换不动，以及新架构顺手照出来的几处旧账。

## 一、除了机器码，ARM 上什么都不缺

Fun 的大部分能力，根本不碰架构相关的代码。解释器、解析器，还有一票纯逻辑库（set / regex / math / tree / stack / eval / bnf），都是平台无关的 Fun。要下到系统那一层，它走的是可移植 C 库：FFI 用 libffi，文件、进程、网络走 libc，SQLite、libxml2、libcurl、OpenSSL 各有各的实现，正则干脆把 PCRE 的 C 源捆进来，压缩也是现成的 zlib。这些在 aarch64 上照样编、照样跑。

拉成一张表，差异只有两格：

| 能力层 | x64 | aarch64 |
|---|---|---|
| 解释器 / 纯逻辑库 | 有 | 有 |
| FFI、文件、进程、网络、数据库、加密、正则、编码 | 有 | 有（走可移植 C 库） |
| 运行期 C 编译 `lib-tcc` | 完整 | 可用，但后端老 |
| 汇编 / 机器码 `lib-asm`、`NewJit #!asm` | 有 | 缺，而且现在还静默出错 |

看表之前先排掉两个雷，免得误判。原子引用计数：`base.pas` 里 `lockInc` / `lockDec` 那几行内联汇编，只对「真 32 位 x86」开，FPC 在 `CPU64` 上一律走非原子回退。也就是说 x64 的 64 位构建本来就不是原子的，ARM 不算退步。`calc.inc` 里那些 `asm jo` 也只受 `-dCalcOpt` 这个开关管，默认不开，跟架构无关。

## 二、机器码那一层，为什么换不动

`lib-asm.fun` 和 `lib-asm-pro.fun` 里没有一处 `cpu` 判断，只看 `os` 和 `bits`（`lib-asm.fun:11`、`lib-asm-pro.fun:11`）。到了 64 位主机，`lib-asm-pro.fun:44-56` 会往表里塞一批 `mov r64,%16`。在 aarch64 上，这段逻辑照样会把 x86-64 的字节算出来，送进 mmap 出来的可执行页里跑，结果是 SIGILL，或者更糟，什么迹象都没有。

根子在表本身。现有 `asm-list.fd` 是给 x86 用的表，记的是 32 / 64 位 x86 的机器码：键取指令文本，值把操作数拼到尾巴上，比如 `adc al,byte ptr [eax%2]=1240%2`，`%2` 表示操作数是两位十六进制。展开器 `AssemblyPro.Compile`（`lib-asm-pro.fun:62` 起）干的事，就是查表，再按 `%(\d++)` 把值里的占位符换回操作数。

这套「前缀加后缀」的模型，正好长得像变长的 x86：指令 1 到 15 字节不等，操作数当后缀字节往后接。AArch64 不是这么回事。它定长 32 位，操作数不是往后拼，而是挪进那个 32 位字里的固定位段，Rd / Rn / Rm 各占 5 位，`imm12` / `imm19` / `imm26` 各有各的位置。一条 `add x0, x1, #1` 就是一个 32 位整数，没有尾巴可加。

调用约定也是两套。Linux x64 是 System V AMD64，参数进 rdi、rsi、rdx、rcx、r8、r9，返回值在 rax。AArch64 是 AAPCS64，参数进 x0 到 x7，返回在 x0。手写一段 `#!asm`，换个架构基本等于重写。

结论不绕弯：跨架构要的是另一套编码器加另一张表，不是「换一张同格式的表」。AArch64 定长、规则，反倒适合表驱动，把操作数形态映射到一个完整的 32 位模板，再做位域插入，但这套表格式和展开器都是新的，可以在 Fun 里写。

还有个绕不开的约束。表是用 `use ':asm-list.fd.2.gz'` 取的，而 `use ':file'` 在 parse 期就把文件整块嵌进脚本（`parse.pas` 的 `BuildUse`），没法在运行期「按 host 挑一个 use」。所以方案是按架构分开：一套表配一个编码器，数据改用 `load()` 从解释器旁边的数据文件读，运行期按 `host.arg().cpu` 选。体积供参考：`asm-list.fd` 1.09 MB，压成 `.fd.2` 523 KB，再 gzip 到 93 KB。

## 三、新架构像一面镜子

移植的副产品，是把那些「只在 x86 上凑巧成立」的假设照出来。这两天上游清了三个，都是 ARM 逼出来的。

第一个最直白。`_hostCpu` 里写的判断是 `CPUARCH64`，比 FPC 的真名 `CPUAARCH64` 少了一个 A。于是 aarch64 一路掉到最后那个 `CPU64`，`'host'.arg().cpu` 报回来的是 `cpu64`（`libase.pas:134`，`5033eda` 改回 `CPUAARCH64`）。少一个字母的错，让「谁知道自己是 ARM」这件事在机器上一直是个假答案。

第二个是空指针。`CParser.CreateRegex` 在不带 `-dRegex` 的构建里不建 `CRegex`，原来的写法直接返回一个没初始化的指针。x86 上没人碰它，也就一直没炸；AArch64 会去解引用那团垃圾，当场崩（`233cd7f`，现在显式 `result.node := nil`）。

第三个是除零。Fun 对浮点 `x / 0` 是要抛 `EZeroDivide` 的，x86 和 ARM32 靠硬件浮点陷阱做到。AArch64 默认把浮点异常掩着，同一个表达式算出的是 `+Inf`。现在加了一段显式的除数检查（`calc.inc`，`3b23036`），让每个目标抛得一样。

顺手还清了两笔老的：WinCE 不支持 `ReadLn(Input)`，控制台输入在那边直接摘掉，好让 wince 编得过去（`1c624dc`）；`make-win64.bat` 里混着 32 位的 WinAPI / WinCE / ARM 宏，删掉之后 x64 才编得过（`eb4ecb6`）。

（吐槽：这些 bug 的共同点，是在原来的机器上全都「没问题」。一个拼错的宏能活这么久，靠的就是没人换 CPU。）

## 四、先让缺口诚实

真去做 ARM 编码器之前，有个更便宜的动作：加架构门禁。非 x86 的 host 上，`lib-asm` 和 `NewJit('#!asm ...')` 应该明确报错，说清「这台机器不支持」，而不是像现在这样静默吐一段 x86 字节然后 SIGILL。能力可以不完整，但不能骗人。`_hostCpu` 也顺手补上 `loongarch64`（需要的话还有 `riscv64`）这一支。

再往上，ARM 真正的可用性只卡在 `lib-tcc` 的 arm64 后端。`src/3rd/tcc` 里确实带着 `arm64-gen.c`，但版权头是 2014 到 2015 年的，是全项目里最老、验证最少的目标，浮点、变参、结构体边界都得逐个冒烟，不能当 x64 用。

龙芯（LoongArch64）排在 ARM 后面。Fun 源码本身几乎不用动，它是 LP64 小端，和 x86_64、AArch64 同构。门槛在工具链：FPC 稳定版 3.2.2 没有这个目标，得用 trunk / 3.3.1 自举；好消息是 FPC 主线（trunk）的 `ffi.pp` 已经带了 `CPULOONGARCH64` 分支，FFI 这条路是通的；坏消息是 TCC 压根没有 LoongArch 后端，比 ARM 还缺一层。所以先验证一件事就够：FPC trunk 能不能稳定编出能跑的 `funcmd`。这一关过了，剩下都是收尾。

## 结语

把 Fun 搬上新 CPU，像给一间老房子换地基。住着没事的地方，一换才发现有几处是靠着老地基的缝站着的。机器码这一层，是唯一真要重砌的墙，别的地方把窗户打开就能用。作者说 Fun 是开窗，C 是没有墙，换架构的时候，你会很清楚自己开的是哪几扇窗，墙又砌在哪里。