VFPU Register Addressing: Public Architecture and Bounded Hardware Confirmation
Wave 4 structured record
Stable ID: FIND-VFPU-ADDR-001
Evidence class: MEASURED / CROSS-MODEL NEEDED. This is an implementation-facing finding grounded in established public VFPU architecture plus a bounded, source-owned PSP-3001 / 6.61 ARK confirmation.
Scope: 128 scalar E-field cases and 14 selected wide cases on one PSP-3001 running 6.61 ARK. Discriminators include triple E=0x20 → [0,4,8], triple E=0x40 → [1,2,3], and quad E=0x60 → [8,12,0,4]. The 498 remaining wide encodings were not measured.
Reproduction confidence: REPEATED SAME DEVICE for the reported corpus; replication on PSP-1000/2000/Go/Street remains requested. The result is not a claim of exhaustive hardware equivalence.
Novelty/support: N1 established public architecture, N2 hardware reconfirmation, N3 useful implementation discriminators. It supports the companion experiment EXP-VFPU-ADDRESS-20260805-A.
Status: HARDWARE MEASURED / PRIOR ART · Scope: PSP-3001, firmware 6.61 with ARK · Last reviewed: 2026-08-11
Public architecture first
Public VFPU documentation describes 128 physical 32-bit scalar registers arranged as eight matrices. Vector and matrix views alias that physical file; they are addressing views, not separate storage. A recompiler can therefore keep a physical v[128] file and decode vector or matrix operands into scalar indices. This representation is established prior art, not a claim of discovery.
The PSP VFPU reference is the public architectural starting point. The current Nakagawa state model keeps the physical file in vfpu_interp.c; the translation and interpreter paths consume decoded scalar indices.
Bounded hardware confirmation
Novelty posture: N1/N2 (bounded re-verification and precision extension only); no higher novelty discovery label is claimed.
A source-owned probe ran on the PSP-3001/6.61-ARK target with a thread carrying THREAD_ATTR_VFPU. All 128 scalar E-field encodings were measured and matched the current physical mapping byte-for-byte in the accepted controls. Fourteen selected wide encodings were also measured. The wide sample included the E=0x60 quad case, where lane addressing wraps across the row boundary rather than saturating or raising an error.
| Surface | Observed coverage | Evidence class |
|---|---|---|
| Scalar E-field encodings | 128 / 128 | HARDWARE MEASURED |
| Selected wide encodings | 14 direct cases | HARDWARE MEASURED |
| All possible wide width combinations | 14 of 512 directly observed | remaining cases DERIVED or SYNTHETIC |
Prior-art survey (2026-08-11)
Checked the DavidGF VFPU reference, PSPDEV/PSPSDK materials, the PSP Developer Wiki COP2 page, PSPAutotests vector source and expected output, PPSSPP VFPU decoder/interpreter paths, YAPSPD and archived PSP technical references, and PSP RE HQ. Found: the public 128-scalar/eight-matrix model, broad vector-operation tests, and emulator implementation context. No checked source presented the exact 128/128 scalar plus 14 selected wide PSP-3001/6.61-ARK confirmation matrix or the E=0x60 row/lane-wrap observation. This page therefore claims bounded re-verification/precision extension only. Absence from this survey does not prove that no prior art exists elsewhere.
What the result does and does not show
The result re-verifies and extends the precision of a public register-file model for one PSP model and firmware/CFW environment. It does not prove every width, prefix, or control encoding on every PSP revision. A probe without the VFPU thread attribute reports a coprocessor-unusable condition; that is an infrastructure prerequisite, not a register-addressing result.
Do not turn the 14 wide cases into a universal hardware law. The responsible claim is: “the listed scalar and selected wide encodings behaved this way on PSP-3001/6.61-ARK.” New models, firmware versions, and unmeasured combinations remain open.
Hardware traceability
Directly observed: 128/128 scalar encodings and 14 selected wide cases in two accepted runs on PSP-3001/6.61-ARK, including E=0x60. Interpretation: physical-file agreement and row/lane wrapping. Source/probe provenance: the source-owned probe setup and aggregate result record are available for review; restricted captures/private inputs are not published. Untested: the remaining 498 wide combinations, other models, and other firmware/CFW.
Reproduction and review
Keep scalar mapping, lane order, row wrap, and probe setup as separate assertions. Publish a coverage table and distinguish HARDWARE MEASURED from DERIVED/SYNTHETIC outputs. Restricted captures and private game inputs are not required for a public replication attempt. Use the Hardware Oracle Methodology and Evidence Standard to qualify the result.
Related reading: Static Recompilation Architecture, Open Research Questions, and VFPU Transcendentals and Denormals when available.
Contradiction/replication: See REG-CONTRADICTIONS-001 for target-boundary and authority distinctions, and REG-HARDWARE-FINDINGS-001 for the model matrix. Requests should report model, firmware, raw inputs, and output digests; do not upload private captures or retail assets.
Current source anchor — Wave 4
The implementation comparison was refreshed against src/rt/recomp.c at main 04daf156. Older source links, where present, remain historical lineage; this exact revision is the current public-head anchor.