WATaBoy：将 Game Boy 指令 JIT 编译为 WASM，性能超越原生解释器

背景

在移动设备（特别是 iOS）上运行高性能模拟器一直是一个巨大的挑战。以著名的 GameCube/Wii 模拟器 Dolphin 为例，它无法上架 App Store 的核心原因在于 Apple 对即时编译（JIT, Just-In-Time）的限制。Apple 出于安全考虑，禁止在 App Store 的应用中进行 JIT 编译，这意味着 Dolphin 无法在运行时将机器码动态编译为原生指令执行。

然而，Apple 对 Web 浏览器引擎存在一个例外：JavaScriptCore（WebKit 的 JS 引擎）和 WebAssembly（Wasm）允许 JIT 编译。当 JavaScript 函数被频繁调用时，引擎会将其优化并编译为原生机器码；同理，WebAssembly 字节码最终也会被浏览器编译为原生代码执行。

基于这一例外，作者提出了一个大胆的想法：既然不能直接生成原生机器码，是否可以生成 WebAssembly 字节码，然后“搭便车”利用浏览器的 JIT 编译器将其转换为原生代码？尽管已有如 The Jiterpreter 和 v86 等项目证明了在 Wasm 内部进行 JIT 代码生成的可行性，但在当时，尚无游戏机模拟器采用此技术，且缺乏将其性能与原生解释器进行对比的基准测试。

因此，作者在其本科毕业设计项目中构建了 WATaBoy——一个 Game Boy 模拟器。该项目旨在通过对比“原生解释器”与“JIT-to-Wasm”两种实现方式，验证后者在移动环境下的可行性与性能优势。

核心内容

WATaBoy 的核心技术挑战在于如何在受限环境下实现高效的即时编译，并解决 Wasm 架构带来的执行障碍。

1. 模拟器架构与优化策略

Game Boy 并非像第六代主机那样能从 JIT 中获益巨大，但其架构简单，适合用于概念验证。为了保持周期准确性（cycle-accurate）的同时利用 JIT，作者借鉴了 GameRoy 博客中提出的优化技巧：

• 中断预测：预测中断何时发生。
• 回退机制：当 JIT 代码块可能被打断时，回退到解释器执行。
• 惰性求值：通过内存映射 I/O (MMIO) 访问的非 CPU 组件进行惰性求值。

虽然 GameRoy 的 JIT 仅针对 x86 架构，但其优化思路完全适用于 WATaBoy 的 JIT-to-Wasm 实现。

2. 技术实现：Rust 生成 Wasm 字节码

为了在底层操作 Wasm，作者没有使用 wasm-bindgen 或 wasm-pack 等高层工具，而是采用了类似 "Rust to WebAssembly the hard way" 的方法，通过 C ABI 在 Rust 和 JavaScript 之间传递数据（使用指针和缓冲区长度，而非 JS 对象）。

• 依赖库：使用 wasm-encoder crate 来构建 Wasm 字节码。虽然该库并非专为 JIT 设计，存在一定的样板代码，但比手动编写原始字节数组要方便得多。
• 代码生成示例：作者展示了一个生成 add 函数字节码的过程。通过 wasm-encoder 的构建器模式，依次编码类型部分（Type Section）、函数部分（Function Section）、导出部分（Export Section）和代码部分（Code Section）。最终生成的字节码包含获取局部变量、执行 i32_add 指令等逻辑。

3. 编译、链接与执行流程

由于 WebAssembly 采用哈佛架构（指令和数据存储分离），而非冯·诺依曼架构，程序无法直接执行自身生成的字节码。必须借助宿主环境（通常是 JavaScript）来完成以下三个步骤：

1. 编译与实例化 (Compile & Instantiate)： 使用同步编译接口，将生成的字节码缓冲区编译并实例化为 Wasm 模块。
2. 链接 (Link)： 将从新模块中生成的函数添加到主模块的间接函数表（Indirect Function Table）中，并记录该函数在表中的索引，以便后续调用。
3. 分发/执行 (Dispatch)： 使用 call_indirect 指令，通过间接函数表中的索引来调用生成的函数。

在 Rust 端，通过 #[link(wasm_import_module = "env")] 声明一个外部函数 link_new_module，该函数由 JavaScript 实现，负责接收字节码缓冲区并返回新函数在表中的索引。随后，Rust 代码利用该索引执行 call_indirect 来完成实际计算。

关键要点

• 绕过 iOS JIT 限制：利用 Web 浏览器引擎对 Wasm 的 JIT 支持，实现了在 iOS 等受限平台上运行高性能模拟器的可能性。
• JIT-to-Wasm 而非 Wasm JIT：作者特意使用“JIT-to-Wasm”这一术语，以区别于 JS 引擎将 Wasm 编译为机器码的过程。这里的 JIT 指的是将模拟器指令动态编译为 Wasm 字节码。
• 底层交互方式：摒弃了高层工具链，直接使用 wasm-encoder 和 C ABI 进行底层字节码生成与数据交换，以获取更精细的控制权。
• 哈佛架构的执行约束：Wasm 字节码不能直接执行，必须通过宿主环境（JS）进行编译、实例化和链接，并通过间接函数表进行调用。
• 性能对比基准：该项目作为概念验证，核心目标是证明 JIT-to-Wasm 方案在 Game Boy 模拟场景下，性能优于传统的原生解释器。

意义与影响

WATaBoy 项目不仅是一个本科毕业设计，更是对移动端模拟器技术边界的一次重要探索。

1. 移动端模拟器的新路径：它证明了在禁止原生 JIT 的环境中，通过 Wasm 间接实现 JIT 加速是可行的。这为未来在 App Store 上架高性能复古游戏模拟器提供了技术参考。
2. Wasm 动态代码生成的实践：虽然 jit-interface 提案未来可能允许在 Wasm 内部直接进行函数创建，但目前通过 JS 宿主进行动态编译和链接仍是主流且有效的方案。WATaBoy 详细展示了这一流程的具体实现细节，填补了相关技术文档的空白。
3. 性能优化的可行性验证：尽管 Game Boy 的 CPU 负载相对较低，但该项目验证了 JIT 技术在简化模拟器逻辑、提升执行效率方面的潜力。对于更复杂的模拟器，这种技术路线可能带来更显著的性能提升。
4. 开源社区的知识贡献：作者公开了从 Rust 生成 Wasm 字节码、处理间接调用以及跨语言边界数据传递的具体代码示例，为其他希望深入 Wasm 底层开发的开发者提供了宝贵的参考资料。