PlayStation 2 作为一代经典游戏主机，其硬件架构的复杂性至今仍令逆向工程和移植开发者头疼不已。PS2Recomp 作为一款新兴的静态重编译工具，其核心挑战之一便是如何精确模拟 PS2 独特的内存系统与地址转换机制。与传统模拟器在运行时逐条翻译指令不同，PS2Recomp 采用提前编译的方式将 MIPS R5900 指令转换为 C++ 代码，这一设计选择使得内存映射的实现必须更加严谨和高效。本文将深入剖析 PS2Recomp 在内存映射与地址转换方面的工程实现策略，为理解现代重编译技术提供参考。
内存架构背景与挑战
PlayStation 2 的内存系统由多个独立且功能各异的区域组成。主内存采用 32MB 的 RDRAM，提供高速数据访问带宽；16KB 的 Scratchpad RAM 作为高速暂存区，位于 0x70000000 至 0x70003FFF 地址空间；图形合成器 GS 的 VRAM 则通过专用地址空间映射，承载纹理和帧缓冲数据。这些内存区域在物理上相互独立，但在虚拟地址空间中需要通过 MMU 进行统一管理。PS2 的 EE 核心采用 MIPS R5900 处理器，其 MMU 支持分页机制和 TLB 转换，这对重编译器的内存仿真提出了极高要求。更为复杂的是，PS2 还包含独立的 IOP 处理器，用于处理输入输出操作，两个处理器拥有各自独立的地址空间，这种双处理器架构使得内存管理变得更加棘手。PS2Recomp 需要准确模拟这些内存区域的特性，确保重编译后的代码能够在现代 PC 平台上正确运行。
EE 和 IOP 处理器之间的地址空间隔离是 PS2Recomp 必须处理的首要问题。EE 处理器可以访问主内存、I/O 寄存器以及被映射到特定地址范围的设备，而 IOP 处理器则运行独立的程序，有自己的代码和数据空间。在重编译过程中，PS2Recomp 需要为两个处理器分别建立独立的内存上下文，使用 ctx 指针来区分不同处理器的寄存器状态。当重编译代码访问内存地址时，系统必须首先判断该地址属于哪个处理器的地址空间，然后进行相应的地址转换和内存访问。这种设计要求重编译器在翻译阶段就建立清晰的内存分区意识，而非在运行时动态判断，从而提高执行效率。
地址转换机制与 TLB 仿真
PS2Recomp 采用了分层 TLB 查找策略来模拟 EE 核心的内存管理单元。当重编译代码执行内存访问指令时，系统首先在主 TLB 中查找虚拟地址对应的条目；如果未命中，则回退到次级 TLB 进行查找；只有在两次查找都失败的情况下，才执行完整的地址转换流程。这种设计借鉴了现代处理器的 TLB 层次结构，在保证功能正确性的同时兼顾了性能需求。完整的地址转换需要查询页表，将 32 位虚拟地址分解为页目录索引、页表索引和页内偏移三部分，最终得到物理地址。这一过程在传统模拟器中通常会引入显著的性能开销，而 PS2Recomp 通过提前分析和静态转换的方式，将大部分地址转换工作在编译阶段完成，只保留必要的运行时检查。
TLB 重填策略是 PS2Recomp 内存管理的另一个关键环节。当 TLB 未命中发生时，系统不仅需要执行完整的地址转换，还需要将新建立的映射关系缓存到 TLB 中，以便后续访问能够快速命中。PS2Recomp 的实现中，次级 TLB 的重填总是会触发，这确保了地址转换结果被记录下来；而对于主 TLB，只有当转换结果指向真实存在的物理内存时才会进行缓存。这一策略有效地避免了无效映射对 TLB 空间的占用，同时保证了常用地址映射能够快速访问。在实际运行中，这种设计能够显著减少 TLB 未命中带来的性能损失，特别是在访问频繁变化的堆内存区域时效果尤为明显。
物理地址的有效性检查是地址转换流程的最后一道防线。PS2 的硬件在访问无效物理地址时会触发总线错误异常，但在某些特殊情况下，PS2 的行为与文档描述存在差异。例如，0x70004xxx 地址范围的写入操作在真实硬件上不会触发总线错误，而是返回零值，这可能是硬件设计中的特殊处理。PS2Recomp 需要精确模拟这些边界情况，确保重编译后的程序在各种极端输入下都能表现出与原硬件一致的行为。这要求开发者深入理解 PS2 硬件的每一个细节，并将这些知识转化为准确的内存访问检查代码。
显存与专用设备地址映射
图形合成器 GS 的 VRAM 映射是 PS2Recomp 内存系统中最复杂的部分之一。GS 使用独立的地址空间来访问帧缓冲和纹理数据，这些地址在物理上并不对应主内存，而是连接到专用的视频处理单元。在重编译环境中，PS2Recomp 需要为 GS 访问建立特殊的内存处理逻辑，当代码尝试读取或写入 GS 地址范围时，系统必须将操作重定向到专门的帧缓冲模拟结构。这一过程涉及地址的重新计算和数据的格式转换，因为 PS2 的像素格式与现代显卡存在显著差异。现代 PC 平台通常使用 RGBA8888 格式，而 PS2 的帧缓冲可能采用索引色或其他压缩格式，这增加了显存映射的复杂度。
向量处理单元 VPU 的微代码加载和执行也需要特殊的内存支持。VPU 拥有自己的微代码存储器，其中的程序需要在运行时加载到 VPU 内部。PS2Recomp 的内存系统必须为微代码传输提供通道，同时处理 VPU 与主内存之间的 DMA 数据传输。DMA 操作涉及源地址、目标地址和传输长度的解析，这些参数都来自重编译代码中的寄存器或内存值。PS2Recomp 通过在运行时环境中实现完整的 DMA 控制器模拟，确保重编译代码能够正确触发和控制数据传输，而无需修改原始游戏逻辑。
重编译代码的内存布局对应
PS2Recomp 采用 literal translation 策略进行指令翻译，这意味着每条 MIPS 指令都会被直接转换为对应的 C++ 操作。例如，加法指令 addiu $r4, $r4, 0x20 会被翻译为 ctx->r4 = ADD32 (ctx->r4, 0X20)。这种翻译方式虽然简单直接，但要求内存访问指令必须精确模拟原处理器的行为。32 个通用寄存器通过 ctx 结构体的成员变量访问，ctx 指针作为第一个参数传递给每个翻译后的函数，使得重编译代码能够访问完整的处理器状态。内存读取操作使用封装好的 READ 函数，该函数负责执行地址转换和边界检查，然后将数据返回给调用者。
重定位信息的处理是内存映射的另一个关键方面。PS2 游戏通常使用 ELF 格式的可执行文件，其中包含大量的重定位条目，描述了需要在加载时修正的地址引用。当 PS2Recomp 解析 ELF 文件时，它会收集所有重定位信息，并在翻译阶段将这些相对偏移转换为绝对地址。对于覆盖机制（overlays）的支持更为复杂，因为覆盖区域在运行时会被动态加载和卸载。PS2Recomp 需要在运行时环境中实现覆盖管理器的功能，追踪当前加载的覆盖模块，并在访问跨覆盖边界的函数或数据时触发相应的加载操作。这种设计确保了重编译后的程序在内存使用模式上与原始游戏保持一致。
工程实践要点
在实现 PS2Recomp 的内存映射系统时，开发者需要注意几个关键的技术决策点。首先是内存分配策略的选择，PS2Recomp 使用 TOML 配置文件来定义内存区域的属性，包括起始地址、大小和访问权限。这种声明式配置方式使得内存布局的调整变得简单直观，无需修改核心代码。其次是缓存一致性的处理，PS2 的 EE 核心拥有 8KB 的数据缓存，缓存在某些情况下可能与主内存内容不一致。PS2Recomp 必须在适当的时机执行缓存刷新操作，特别是在 DMA 传输和 I/O 操作之前。最后是异常处理机制的设计，TLB 未命中、地址越界和总线错误等异常情况都需要被正确模拟，确保重编译代码在遇到错误时能够优雅地终止或按照预期行为处理。
现代 x86-64 平台的特性为 PS2Recomp 的内存实现提供了便利条件。SSE4 和 AVX 指令集能够高效处理 128 位的 MMI 指令，这是 PS2 向量处理的关键扩展。64 位寻址能力消除了 32 位平台的地址空间限制，使得 32MB 的主内存可以在现代 PC 上轻松映射。PS2Recomp 生成的 C++20 代码依赖编译器优化来将高级语言构造转换为高效的机器码，这种方法在保持代码可读性的同时实现了良好的运行性能。开发者可以通过调整编译选项和内存布局参数来平衡性能和兼容性，以适应不同游戏的需求。
参考资料：PS2Recomp GitHub 仓库（https://github.com/ran-j/PS2Recomp）、DeepWiki 技术文档（https://deepwiki.com/ran-j/PS2Recomp）