PlayStation 2 诞生于 2000 年，其独特的 Emotion Engine 架构包含 MIPS R5900 主处理器与两个矢量单元（VU0、VU1），这一硬件组合在二十余年后的今天仍然对模拟器开发者构成挑战。传统模拟器如 PCSX2 通过动态重编译与解释器相结合的方式逐条翻译 R5900 指令，但时序精确性与性能之间的权衡始终存在。PS2Recomp 项目则采取了一种截然不同的策略：将 PS2 ELF 二进制文件静态重编译为原生 C++ 代码，从而彻底摆脱运行时的翻译开销。本文将深入剖析这一工具的技术架构、核心工程挑战以及实际应用中的关键参数。
静态重编译的核心流水线
PS2Recomp 的工作流程可以划分为四个关键阶段。首先是 ELF 解析阶段，工具使用 ELFIO 库读取 PS2 可执行文件，提取函数边界、符号表、重定位信息以及覆盖（overlay）区块。值得注意的是，大量 PS2 游戏保留了完整的符号表，这为函数级翻译提供了天然的分界点，降低了控制流分析的复杂度。第二阶段是指令解码，R5900 作为 MIPS IV 指令集的超集，其 32 位基础指令与 128 位多媒体扩展（MMI）指令需要分别处理。第三阶段是代码生成，每条 R5900 指令被字面对应到一条 C++ 操作，例如 addiu $r4, $r4, 0x20 被翻译为 ctx->r4 = ADD32(ctx->r4, 0X20)。最后阶段是运行时链接，生成的 C++ 代码需要与 ps2xRuntime 库链接，由后者提供内存管理、系统调用包装以及 PS2 硬件仿真。
这一流水线设计的精妙之处在于其透明性。由于采用字面映射而非高级语义抽象，生成的代码可以被标准 C++ 编译器优化，同时开发者能够直接阅读输出来定位翻译错误。然而，字面映射也意味着翻译器本身不需要理解复杂的编译器优化策略，这大大简化了实现难度。配置方面，PS2Recomp 使用 TOML 文件指定输入 ELF 路径、输出目录、函数存根（stub）列表、需要跳过的函数以及需要修补的指令地址。例如，针对需要调用标准库函数的代码，可以在配置中声明 stubs = ["printf", "malloc", "free"] 以注入宿主平台的实现。
128 位多媒体指令与矢量单元的特殊处理
R5900 的多媒体扩展指令（MMI）是 PS2Recomp 必须攻克的第一道难关。MMI 指令操作 128 位数据，涵盖加法、乘法、逻辑运算以及位移等操作。PS2Recomp 要求编译环境支持 SSE4 或 AVX 指令集，因为现代 x86-64 处理器的 SIMD 单元可以直接映射 PS2 的 128 位向量操作。例如，MMI 的 pmaddw（packed multiply-add word）指令在 C++ 中可以通过 _mm_madd_epi16 或等价的内建函数实现。这一设计选择意味着生成的可执行文件只能运行在支持相应 SIMD 扩展的现代处理器上，但同时也保证了向量运算的性能与原生代码无异。
矢量单元（VPU）的处理则更为复杂。PS2 拥有两个独立的矢量单元，其中 VU0 既可以与主处理器并行运行，也可以在宏模式（macro mode）下作为协处理器使用。PS2Recomp 当前版本支持 VU0 的宏模式翻译，即 VU0 微代码被当作普通函数翻译为主循环的一部分。然而，VU1 的微代码支持仍然有限，原因在于 VU1 通常运行独立的微程序，且与 Graphics Synthesizer（GS）存在紧密的数据交互。对于依赖 VU1 进行复杂几何变换或特效计算的游戏，重编译后的代码可能需要额外的手工适配或运行时模拟层。
控制流重建与运行时架构
静态重编译面临的一个根本性挑战是控制流重建。与动态重编译不同，静态翻译无法依赖运行时收集的分支信息来推断间接跳转的目标。PS2 游戏大量使用函数指针表、虚函数调用以及基于运行时计算的分跳转，这些模式在缺少符号信息的情况下难以自动解析。PS2Recomp 的应对策略是充分利用 ELF 文件中保留的符号表，将大多数间接调用转化为基于符号地址的直接调用。对于缺少符号的代码，开发者可以通过配置文件的 skip 列表跳过无法安全翻译的函数，或者在运行时层实现解释器回退。
ps2xRuntime 库是 PS2Recomp 生态中不可或缺的组成部分。它提供了 PS2 硬件抽象层，包括 32MB 主内存的模拟、DMAC（直接内存访问控制器）的行为建模、基础系统调用（如 printf、malloc）的宿主平台实现，以及输入设备的映射。由于 Graphics Synthesizer 的渲染管线与现代 GPU 差异巨大，运行时层目前需要外部实现或使用社区提供的 GS 仿真库。这解释了为什么 PS2Recomp 无法像 N64: Recompiled 那样实现一键式移植 ——PS2 的图形子系统复杂性决定了每款游戏都需要针对性的适配工作。
工程实践中的关键阈值与监控点
基于 PS2Recomp 的当前状态与社区反馈，以下参数与阈值可作为实际使用时的参考基准。编译环境要求 CMake 3.20 以上与 C++20 兼容的编译器，项目主要在 MSVC 下测试通过。生成的 C++ 代码大小与原始 ELF 成正比，典型游戏的输出规模在数百 KB 到数 MB 之间，编译时间取决于代码量与现代 CPU 的编译性能。运行时内存需求通常为原始 PS2 内存（32MB）的两到三倍，以容纳翻译后的代码镜像与仿真层的数据结构。
社区经验表明，重编译成功率与游戏对 PS2 特定硬件特性的依赖程度负相关。使用简单引擎、较少依赖 VU1 微代码的游戏（如早期 2D 作品或静态摄像机视角的 3D 游戏）更容易成功移植。而那些深度利用 GS 特技渲染、VU 粒子系统或精确时序依赖的游戏，则需要更多的手工调优。此外，PS2Recomp 尚处于实验阶段，代码生成器与运行时层仍在快速迭代，使用者应预期 API 变更并保持对上游仓库的关注。
与传统模拟器的互补关系
PS2Recomp 的出现并不意味着 PCSX2 等传统模拟器将被取代。两者代表了两种不同的技术路径：模拟器追求兼容性与普适性，重编译追求性能与可优化空间。对于游戏模组社区而言，重编译生成的原生代码更容易嵌入修改点与现代渲染后端，从而实现超越原版的视觉增强与操控改进。N64: Recompiled 项目已经证明了这一模式的可行性，其生成的《时之笛》与《马里奥奥德赛》原生版本支持更高分辨率、更宽视野以及现代输入设备。PS2Recomp 若能成熟，有望为 PS2 庞大的游戏库（约 3800 款作品、1.55 亿台主机销量）开启类似的现代化之门。
综合来看，PS2Recomp 展示了静态重编译在复古游戏现代化中的潜力，同时也揭示了复杂硬件架构对自动化翻译工具的固有制约。其采用字面指令映射、SSE/AVX 向量加速以及符号驱动控制流重建的策略，为类似项目（如 Xbox 360 的 XenonRecomp）提供了可参考的技术路线。对于希望深入理解二进制翻译或参与游戏保存工作的开发者而言，PS2Recomp 是一个值得研究与贡献的工程案例。
参考资料
- PS2Recomp 项目仓库：https://github.com/ran-j/PS2Recomp
- R5900 模拟实践（Rich Whitehouse）：https://richwhitehouse.com/index.php?postid=62