VFPU Transcendentals and Denormals: A 46-Input Hardware Comparison
Wave 4 structured record
Stable ID: FIND-VFPU-TRANSCEND-001
Evidence class: MEASURED / REPLICATION WANTED. A source-owned comparison used one 46-input raw IEEE-754 vector and eight VFPU helpers on PSP-3001 / 6.61 ARK; PSP matched the Nakagawa implementation on the eight reported digests, while PPSSPP differed on several helpers.
Scope: The measured vector covers vrcp, vrsq, vsqrt, vasin, vlog2, vsin, vcos, and vexp2. It is a bounded corpus, not an exhaustive numerical conformance claim. Controls ruled out the tested host FTZ/DAZ and table/CWD explanations for the denormal edge.
Reproduction confidence: ONE-RUN PRELIMINARY on the reported hardware fixture. Cross-model confirmation and an independent raw-input replay are requested before broadening the claim.
Novelty/support: N3 hardware observation, N4 implementation-discriminating digests. It supports EXP-VFPU-TRANSCEND-20260805-A and the separate denormal finding FIND-VFPU-DENORM-001.
Status: HARDWARE MEASURED / DIFFERENTIAL · Scope: PSP-3001, firmware 6.61 with ARK · Novelty posture: N3 candidate, pending independent reproduction · Last reviewed: 2026-08-11
Question
Do a recompiler’s VFPU transcendental results preserve the PSP’s treatment of raw IEEE-754 inputs, including subnormals? The bounded comparison used one shared vector of 46 input bit patterns, eight operations, and FNV-1a digests. The input corpus is described by bit patterns so that the harness does not accidentally normalize denormals before the operation.
Observed comparison
| Path | Result | Evidence class |
|---|---|---|
| PSP-3001 / 6.61-ARK | all eight operation digests matched Nakagawa | HARDWARE MEASURED |
| Nakagawa interpreter | matched the hardware digests in the accepted vector | IMPLEMENTATION FACT / DIFFERENTIAL |
| tested local PPSSPP paths | several operation digests differed | DIFFERENTIAL, build-specific |
One useful split was vrcp: the interpreter matched the hardware digest, while the JIT in the tested local build produced a different digest. That is a reproduction lead, not a claim that every PPSSPP release or configuration behaves the same way.
Denormal control
For the minimum positive subnormal input in the vector, the PSP measurement produced vsqrt → +0 and vrsq → +inf. The tested local PPSSPP path returned finite values for those examples. The public PSP Developer Wiki also records the broader prior-art rule that VFPU denormals are treated as zero; that context does not supply the bounded digest matrix reported here. The host harness separately verified that the denormal bit patterns survived memcpy and the floating-point call at both O0 and O2, so a host-language conversion was not the immediate explanation for the difference.
Table files and scope
All 15 operation-table files compared between the tested PPSSPP checkout and Nakagawa were byte-identical. That supports checking the table data and the execution path separately. It does not establish an architectural guarantee for all inputs, all JIT modes, or all PPSSPP commits. Reproduce against a named PPSSPP release/build configuration and report each input/output pair before aggregating a digest.
Prior-art survey (2026-08-11)
Checked the DavidGF VFPU reference, PSPDEV/PSPSDK materials, the PSP Developer Wiki COP2 page, PSPAutotests vector source/expected output, PPSSPP interpreter and JIT sources, JPCSP lineage noted by the PSPAutotests source, YAPSPD and archived PSP technical references, and PSP RE HQ. Found: public operation/addressing descriptions, a denormal-as-zero statement, broad vector expected outputs, and separate emulator execution paths. I did not find, in the checked sources, this exact combination of a 46-raw-bit-pattern corpus, eight-operation digest comparison, PSP-3001/6.61-ARK results, and the bounded local PPSSPP interpreter/JIT split. That is the narrow addition claimed here. Absence from this survey does not prove that no prior art exists elsewhere; N3 remains a candidate pending independent reproduction, not a discovery claim.
Hardware traceability
Directly observed: one PSP-3001/6.61-ARK run, the eight operation digests, and the O0/O2 bit-preservation controls. Interpretation: the bounded denormal and interpreter/JIT differences. Source/probe provenance: the source-owned probe summary and named differential configuration are available for review; raw capture, private paths, and retail-derived bytes are not published. Repeatability: cross-device, cross-firmware, and cross-build repeatability is untested. Untested: other input corpora, PPSSPP configurations, and universal behavior.
Public-safe evidence
- HARDWARE MEASURED: one PSP-3001/6.61-ARK run and its controls.
- DIFFERENTIAL: a named local PPSSPP configuration compared operation digests; the configuration and commit must be recorded for a fresh reproduction.
- IMPLEMENTATION FACT: current Nakagawa VFPU execution is public in the transcendental kernels and the operation dispatch.
- PRIOR ART: the DavidGF reference, PSP Developer Wiki COP2 page, PSPAutotests vector source/expected output, and PPSSPP interpreter/JIT provide public architectural, numeric, and implementation context.
Use the Hardware Oracle Methodology and Evidence Standard when labeling a new run. The raw capture, private paths, and any retail-derived bytes are intentionally not published.
Related reading: VFPU Register Addressing and Open Research Questions.
Authority boundary: Software agreement does not replace real-PSP authority; see CONFLICT-REAL-HARDWARE-AUTHORITY-001 and the REG-HARDWARE-FINDINGS-001. Replicators should publish model, firmware, raw IEEE-754 inputs, operation order, and output digests without private captures or game 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.