PSP Cache, Scratchpad, and Address-Alias Semantics
Type: REFERENCE Status: MAINTAINED Scope: Cached and uncached aliases, cache maintenance, 16 KiB scratchpad, DMA/GE visibility, and self-modifying-code boundaries. Last reviewed: 2026-08-11
Static recompilation must preserve the fact that PSP guest addresses can name the same physical memory through different cached and uncached aliases. Cache maintenance is a semantic boundary around CPU, GE, DMA, and instruction fetch—not a generic host memory fence.
What the public sources agree on
The PSP Developer Wiki cache guide describes dirty cache lines, a non-snooping relationship with other PSP units, and the uncached alias formed by setting the 0x40000000 bit. It explicitly warns that cached writes may not be visible through an uncached alias and that an uncached write can later be overwritten by a dirty cached line. The PSP address-map documentation identifies cached/uncached segments and a 16 KiB Allegrex scratchpad; the CPU page provides the corresponding architectural context.
PSPSDK’s exact utility reference lists cache-maintenance functions, including writeback/invalidate operations. Treat whole-cache, range, data-cache, and instruction-cache operations as distinct API families until a measured contract justifies coalescing them.
cached alias A: CPU store -> dirty line (not yet in RAM)<br>uncached alias B: GE/DMA read -> may see older RAM<br>writeback(A) -> RAM becomes current<br>invalidate(A) -> future CPU load refetches RAM<br>I-cache invalidate -> instruction fetch can observe new code
Scratchpad is not an ordinary cache alias
The scratchpad address range is a small on-chip memory region, not a second spelling of main RAM. A translator should preserve its address class and bounds rather than route every low address through the same heap. Public address-map sources establish the region; title-specific allocation and aliasing assumptions remain separate questions.
SOURCE DISAGREEMENT: capacity and line-size wording
GE, DMA, and self-modifying code
Before handing a command list or buffer to a non-CPU unit, the relevant guest cache operation must be represented. The GE page’s stall protocol and the GE synchronization reference therefore cannot be reduced to a renderer fence. For generated or modified code, data writeback plus instruction-cache invalidation are separate obligations. The public evidence supports the boundary, not a universal “flush everything” shortcut.
In Nakagawa, memory ownership and guest access are implemented across the current recomp.h ABI and runtime files. These links are source-level anchors; they do not stand in for hardware proof.
Safe translation rule
Carry an address class (cached main RAM, uncached alias, scratchpad, VRAM/MMIO) alongside the numeric address. Keep writeback, invalidate, and instruction-cache invalidation visible in the guest operation log. A host implementation may optimize equivalent operations only after a production-path regression proves that guest-visible ordering and output are unchanged.