KartPad 是一款让 Mario Kart Wii 与 Retro Rewind 在 iOS、iPadOS、macOS、tvOS 和 Android 上原生运行的免费开源项目。它不是 Wii 模拟器，也不使用 PowerPC JIT——而是通过"静态重编译"（Static Recompilation）技术，把游戏的 PowerPC 代码提前翻译成 ARM64 原生机器码，配合 Vulkan 或 Metal 渲染。本文用通俗语言讲清：这和普通模拟器有什么本质区别，以及这套原理为什么既快又"挑食"。

快速结论：KartPad 和 Dolphin 模拟器差在哪？

如果你玩过模拟器，第一反应可能是："这又是一个 Wii 模拟器吧？"——不是。官方 FAQ 对此的回答只有一句：

它是指向特定游戏（受支持的 Mario Kart Wii 与 Retro Rewind 配置）的静态重编译，不能加载任意 Wii 游戏。

三种"跑 Wii 游戏"的技术路线，核心差异一目了然：

KartPad 走的是第三条路。它的底座是 WiiCompiled 精确记录了这个翻译器基线的 commit 与用途："Primary static translator and runtime baseline"。

静态重编译原理：三步看懂"把 PowerPC 装进手机"

第一步：翻译——把 PowerPC 变成 C++ 源码

传统模拟器在游戏运行时"读一条、翻译一条"。静态重编译则相反：在构建 App 之前，翻译器（translator）就把整个游戏的 PowerPC 可执行文件（DOL）逐函数翻译成 C++ 代码。

这一步是离线完成的、确定性的。以 Mario Kart Wii 为例，翻译器使用内置的 29,792 条函数映射表做递归发现，最终从真实的 PAL DOL 输出了10,836 个 C++ 函数单元（见 docs/SEMANTICS.md 的 "Real title surface" 一节）。你可以理解为：把一本日文小说（PowerPC 机器码）整本提前译成了英文（C++ 源码），而不是等读者读到哪页再口译哪页。

第二步：编译——C++ 变成 ARM64 原生指令

翻译出的 C++ 不是直接跑的，它还要经过一次标准编译：C++ → ARM64 机器码，打进 App 的安装包里。之后游戏代码就在你的 iPhone 或安卓手机上以原生 ARM64 指令执行，CPU 不再需要"猜"任何 PowerPC 指令的含义。

这也是 FAQ 里那句回答的由来：

iPhone/iPad 上的 KartPad不做 PowerPC JIT：代码在构建期就翻译并编译完成。任何新的可执行配置（比如 Mod 改了代码）都需要一个新的 App 构建。

第三步：运行时接管——内存、调度、渲染

翻译只解决了 CPU。游戏还依赖 Wii 的内存布局、操作系统服务和图形 API（GX）。KartPad 用一套"运行时垫片"（runtime shim）补上这些角色，核心文件在 runtime/translation_shim/：

• memory.h、abi_bridge.h：为翻译出的代码提供带安全检查的"虚拟 Wii 内存"和调用约定，保证翻译代码读写的是模拟的 Wii 地址空间，而不是手机的真实内存；
• 协作式 guest_scheduler：每个"游戏线程"保存完整 CPU 快照，在模拟的 OS/HLE 边界主动让出——不依赖 Windows 纤程，也不依赖 iOS 上受限的上下文切换 API（决策过程记录在 docs/PORTABILITY.md 的 "G5 scheduler decision"）；
• 图形走 Aurora 的 GX 兼容层，Android 上输出到 Vulkan、Apple 平台走 Metal。

"逐位精确"：为什么浮点语义是整个项目的生死线

静态重编译听起来很顺，但魔鬼藏在细节里：Wii 的 PowerPC 浮点行为（舍入模式、NaN 形态、符号零、异常标志位 FPSCR）和 ARM64 完全不同。游戏逻辑依赖这些细节，差一个比特，赛车物理和存档就可能跑偏。

KartPad 为此建了一个"语义账本"（docs/SEMANTICS.md），把每条规则变成可回归的测试：

• 整数与浮点：移位/掩码、除法边界、四种 float→word 舍入模式、fres/frsqrte估计指令……全部列出并逐一验证；
• 双架构差分：arm64 与 x86_64 两套架构跑同一组测试，Release 下共250,227 项检查，状态哈希必须一致（0xccd5757c4c0643d4）；
• 以 Dolphin 为行为预言机（oracle）：估计指令的期望值不是手写的，而是把锁定版本 Dolphin 的FloatUtils.cpp直接编译出来逐字节比对（对照fixtures/g6/dolphin-estimates.txt）——用"模拟器"当裁判，却不用它跑游戏，这个思路很聪明；
• 10,836 个翻译单元还必须在 arm64 上真实编译通过，并用 ASan/UBSan 跑一遍。

这个流程能抓到的 bug 级别是这样的："某个向上取整转换因为主机优化器忽略了动态舍入环境，返回了 2 而不是 3"——这种问题普通玩法根本测不出来，却必须修。

代价与限制：静态重编译"挑食"的原因

原理讲完，再回头看 KartPad 的几个"怪脾气"，就都合理了：

为什么只支持 PAL RMCP01 版（revision 0）？

因为翻译是构建期完成的、针对特定哈希的 DOL。换一份游戏代码（其他区服、其他修订、不同 Mod 版本），翻译产物就作废，需要重新走一遍"翻译→编译"流程。

为什么 Retro Rewind 更新后要重新构建 App？

Mod 改了游戏代码（Code.pul）= 新的可执行文件 = 需要新的静态翻译。所以 FAQ 明确：下载新 Mod 包或替换Code.pul都无法更新已编译进 App 的代码，必须先更新 KartPad 构建，再装它支持的 Mod 版本（当前锁定 6.13.4）。

为什么游戏数据不随包提供？

App 里装的是编译后的"游戏逻辑"，赛道、贴图、音乐等数据仍需从你自己合法获得的碟片导入（解压出的DATA文件夹，约 2.5 GiB）。这也让软件许可与游戏版权分离，细节见 RIGHTS_AND_LICENSES.md。

为什么首次进赛道会卡一下？

CPU 是静态翻译好的，但着色器仍是首次用到时现场编译（GPU 侧的"JIT"）。性能账本 docs/PERF.md 记录了冷启动时约 793 个着色器在编译、随后从 44 FPS 爬到 60 FPS 的实测——这是静态重编译方案绕不开的另一半成本。

延伸阅读：从仓库里继续深挖

• README.md：平台支持、游戏数据导入与完整 FAQ（含"Is KartPad a general Wii emulator?"条目）
• docs/SEMANTICS.md：PPC/AArch64 语义账本，G6 门禁与 250,227 项检查
• docs/PORTABILITY.md：内存、调度器、渲染逐层移植的决策记录
• docs/PRD.md：产品需求文档，"编译不等于移植，首帧不等于可玩"的工程验收标准
• docs/source-maintenance/README.md：WiiCompiled 翻译器源码如何被锁定与分支维护
• dependencies.lock.json：全部上游依赖（WiiCompiled、Aurora、Dawn、Dolphin 等）的 commit 级锁定
• runtime/：运行时主体源码，runtime/translation_shim/ 为翻译层垫片

一句话总结：模拟器是"随时解释方言"，静态重编译是"提前把整本书翻译出版"——KartPad 用构建期的一次翻译，换来了手机上无 JIT 限制的原生性能，而它只支持一款游戏、只认特定版本的"局限"，恰恰是这项技术原理的直接体现。