静态重编译（Static Recompilation）是一种在运行时之前将字节码或中间指令完全翻译为目标平台原生机器码的技术。与即时编译（JIT）不同，静态重编译的输出是可独立编译、分发的源代码或二进制文件，无需在目标机器上保留原始解释器或虚拟机。PS2Recomp 是一个针对 PlayStation 2 平台的实验性静态重编译工具，它将 MIPS R5900 处理器架构的字节码翻译为可移植的 C++ 代码，使原本只能在特定硬件上运行的 ELF 二进制文件能够在 PC 及任何支持 C++ 编译的平台原生执行。这一技术路线的核心挑战在于逆向工程级别的控制流分析、跨架构指令语义映射以及 PS2 专用硬件功能的模拟抽象。
ELF 解析与符号提取
PS2Recomp 的翻译流水线从解析 PlayStation 2 的 ELF（Executable and Linkable Format）可执行文件开始。ELF 文件包含了二进制镜像的完整结构信息：程序头表（Program Header Table）描述了内存加载段，节头表（Section Header Table）定义了代码节、数据节与重定位信息，而符号表（Symbol Table）则记录了函数入口点与全局变量的地址映射。工具首先读取这些元数据，定位代码段的起始地址与长度，同时收集所有需要重定位的外部函数引用。对于 PS2 游戏而言，典型的 ELF 文件包含主程序入口、动态链接库以及覆盖（Overlay）模块，后者在运行时按需加载，对静态重编译提出了额外的挑战。
在符号提取阶段，PS2Recomp 遍历符号表，识别所有函数符号及其虚拟地址。这些地址作为控制流图（Control Flow Graph）构建的锚点，因为每个函数入口都是一个确定的跳转目标。与动态加载的代码不同，已知地址的函数可以保证其指令序列的完整性，这为静态翻译提供了可靠的基础。然而，PS2 平台广泛使用跳转表（Jump Table）实现 switch-case 分发和虚函数调用，这类间接跳转无法通过符号分析直接解析，需要借助数据流分析从常量传播的结果中推断跳转目标范围。
MIPS R5900 指令到 C++ 的字面映射
MIPS R5900 是 PlayStation 2 使用的定制化处理器内核，基于 MIPS IV 指令集扩展增加了 128 位 SIMD 操作（Media Mode Instructions，MMI）。PS2Recomp 采用字面翻译策略：每一条 MIPS 指令被翻译为 C++ 中对应的函数调用或表达式，而非直接生成优化的机器码。例如，addiu $r4, $r4, 0x20 被翻译为 ctx->r4 = ADD32(ctx->r4, 0X20);，其中 ctx 是模拟处理器上下文的结构体，包含 32 个通用寄存器的模拟状态。这种设计将翻译正确性置于执行效率之上，使得生成的代码易于调试和验证，同时也降低了重编译器的实现复杂度。
128 位 MMI 指令的处理是 PS2 平台翻译的特殊难点。MMI 指令在单条指令中操作 4 个 32 位浮点数或整数向量，支持如向量加法、乘法、混排等操作。PS2Recomp 利用 SSE4 或 AVX 指令集在 x86-64 平台上实现等价的 128 位操作，将 MMI 指令映射到对应的 _mm_* intrinsic 函数。对于向量混排等不直接对应的操作，工具会生成多条指令序列完成语义等价的功能。值得注意的是，MMI 指令的语义与 SSE/AVX 存在差异，例如饱和算术模式（Saturation Arithmetic）在 PS2 上广泛用于图形渲染，但在 x86 SIMD 中需要额外的分支或条件掩码处理。
控制流图重建与间接跳转解析
静态重编译最核心的技术难题在于完整重建程序的执行路径图。直接跳转（JAL、JALR、BEQ 等）的目标地址可以通过指令解码直接确定，但间接跳转（如通过寄存器值的跳转）只有在运行时才能获得具体目标。PS2 游戏大量使用函数指针表、虚表分发以及动态代码生成，这些模式使得静态分析难以穷尽所有可达代码块。PS2Recomp 的策略是结合符号分析与轻量级数据流分析：在已知常量地址的跳转处建立 CFG 节点，对于可能的间接跳转，尝试通过调用点上下文推断其取值范围，如果无法确定则标记为 "未知跳转" 并在生成的代码中保留原始的间接跳转序列。
控制流重建的另一难点在于识别代码与数据的边界。MIPS 架构允许在指令流中嵌入字面量常量、跳转表数据以及对齐填充，这些内容如果不加区分地被翻译为指令，将导致翻译结果的语义错误。PS2Recomp 依赖 ELF 节信息区分代码节与数据节，但对于直接嵌入代码段的数据（如内联常量池），需要借助反汇编器的启发式方法识别。常见的做法是模拟执行起始于已知函数入口，跟随所有可达的分支，标记被访问的地址为代码，未被访问的地址保留为数据或跳过。
运行时抽象与硬件模拟
静态翻译生成的 C++ 代码并非自包含的可执行程序，它依赖一个运行时库（Runtime）来提供内存管理、系统调用处理以及 PS2 专用硬件的模拟抽象。PS2Recomp 在 ps2xRuntime 目录中提供了一个基础运行时实现，封装了处理器上下文结构体、内存读写接口以及 PS2 BIOS 调用的桩函数。翻译后的代码通过这些桩函数访问硬件资源，例如 ctx->r2 作为返回值的约定、系统调用号通过特定寄存器传递等。这种分层设计使得重编译器的核心逻辑与平台相关的模拟逻辑解耦，便于针对不同 PS2 游戏定制运行时行为。
内存管理是运行时实现的关键组成部分。PS2 采用 32 位地址空间，游戏开发者通常直接操作物理地址或通过 MMU 映射的虚拟地址访问显存、纹理缓存与 DMA 控制器。运行时需要维护一份模拟的物理内存视图，并将代码中的地址访问重定向到该视图的对应位置。对于显存访问，运行时可能需要实现帧缓冲模拟或渲染到 OpenGL/Vulkan 纹理。PS2 的 Graphics Synthesizer（GS）是高度定制化的协处理器，其指令包（GIF Packets）格式复杂，目前 PS2Recomp 建议使用外部实现来模拟 GS 功能。
工程实践中的翻译参数与局限
在实际使用 PS2Recomp 进行游戏移植时，开发者需要通过 TOML 配置文件指定若干关键参数。输入文件路径与输出目录是最基本的配置项，工具支持单文件输出或多文件输出两种模式 —— 后者按函数或模块拆分生成的代码，便于大型项目的代码管理与增量编译。对于游戏中引用的标准库函数（如 printf、malloc），可以在 stubs 列表中声明为桩函数，翻译器会生成对应的存根代码而非尝试翻译其实现；skip 列表则用于排除特定函数（如 abort、exit），这些函数通常与退出或调试相关，不影响游戏核心逻辑的执行。此外，patches 配置段允许对指定地址的指令进行修补，适用于绕过特定硬件检查或修复翻译中的已知问题。
当前版本的 PS2Recomp 存在若干已知的工程局限。首先，VU1（Vector Unit 1）微代码支持有限，VU1 负责粒子系统、动画混合等复杂向量计算，其微程序存储在专用微内存中，静态翻译需要解析微代码格式并进行跨架构调度。其次，图形合成器（Graphics Synthesizer）和其他片上协处理器的模拟需要外部实现，这对于大多数 3D 游戏而言是必需的。翻译器的正确性验证也是一个持续的过程，部分 PS2 游戏使用了非标准或混淆的代码序列，可能导致翻译死循环或语义错误。开发者社区正在通过提交 PR 和问题报告逐步填补这些空白，类似于 N64Recomp 项目所建立的开源协作模式。
静态重编译为遗留平台的代码迁移提供了一条不同于传统仿真的技术路径。PS2Recomp 通过将字节码翻译为可移植的 C++ 代码，绕过了动态翻译的性能开销和解释执行的延迟，使得生成的原生代码能够利用现代编译器的优化能力。对于志在复刻经典游戏或研究 PS2 架构的开发者而言，这套工具链提供了可审计、可修改的代码基础，而非封闭的模拟器黑箱。尽管当前仍处于实验阶段，其架构设计已经展示了静态重编译在跨平台移植领域的工程可行性。
资料来源：PS2Recomp GitHub 仓库（https://github.com/ran-j/PS2Recomp）