Match 600+ P2 functions & VU0/splice foundations

[lindskogen]

Brings the P2 decomp from 2567 → 1890 remaining INCLUDE_ASM stubs (~677 functions newly matched) across 118 source files / 23 headers, plus the supporting struct, SIMD, and tooling work to make those matches possible. Every change is verified against the ground-truth checksum (out/SCUS_971.98: OK).

Highlights

• Engine base structs — SO padded to its real 0x550. ALO/LO remain intentionally truncated; subclasses lay out own fields from 0x550 and reach base fields via STRUCT_OFFSET.
• VU0 / SIMD foundation — VU_VECTOR/VU_FLOAT fixed to 128-bit quadwords; VU0 inline-asm idiom established (CalculateWaterCurrent, UpdateWaterBounds, ClipVismapSphereOneHop), unblocking the water/clip math.
• Splice subsystem — large bif/eval/frame/sidebag/ref progress (RefOp BIFs, matrix/vec ops, CFrame, CSidebag node lists); Splice crosses 20%.
• Fully-decompiled units — sort.c (HeapSort), pipe.c, frzg.c.
• Broad leaf/accessor coverage — getters/setters and small helpers across alo, so, sw, sound, mpeg, screen, rog, jt, crv, stepguard, and ~100 other units.

Symbol & comment cleanup (final commit)

• SetAMRegister and OnDifficultyPlayerDeath keep extern "C" — both pass match.sh per-symbol but fail the full checksum when converted (caller-side uchar narrowing / a GCC 2.95 register-allocation flip); documented as load-bearing exceptions.
• Trimmed decomp/tooling-explanation, AI-process, and TODO/blocker comments; condensed the "kept wrapped (unwrapping breaks the checksum)" notes to one line. Struct-field annotations and Doxygen retained.

Notes for reviewers

• Some functions remain wrapped in #ifdef SKIP_ASM on purpose (they match per-symbol but mis-size a still-asm neighbor); the one-line notes say why.

Verification

./scripts/build.sh → out/SCUS_971.98: OK.

[TheOnlyZac]

Wow that's a lot of code! it might a while to review this. The first and main thing I've noticed is that many functions are declared extern "C" in the P2 sources, but I think the P2 sources are all CPP (the only place I've seen C functions are the statically linked libraries).

[TheOnlyZac]

I'm actually getting build errors after configuring the project with the --objects flag (which builds with SKIP_ASM defined), I think because of the discrepancy between the C function declarations in the headers and the CPP function definitions in the source files.

[lindskogen]

@TheOnlyZac I fixed the build errors and a bunch of extern "C". I will resolve the merge conflict.

[TheOnlyZac]

Awesome, thanks. I will start making review comments, but it will take me some time to finish.

[TheOnlyZac]

@lindskogen It seems that the model has littered the code with extern data and function declarations directly above function definitions that reference them, even when those data/functions should logically be declared somewhere else (for example see P2/cm.c). Do you think this can be addressed?

[lindskogen]

@lindskogen It seems that the model has littered the code with extern data and function declarations directly above function definitions that reference them, even when those data/functions should logically be declared somewhere else (for example see P2/cm.c). Do you think this can be addressed?

I will check it out

[545u]

Move function prototypes elsewhere.

[545u]

Unmangle name.

[lindskogen]

Now it's conclusive. The body @ 0x1c0c08 doesn't mask its 2nd param either — move a2,a1 then uses it as a full word throughout (beq a2,v0 / sw a2 / passes a2). So nowhere — not the callers, not the body — does the original narrow the 2nd argument to 8 bits.

Answer: no, no natural combination can unmangle it

The original SetAMRegister__FiUc symbol is essentially a misnomer — it's named as taking unsigned char but is compiled as taking a full int everywhere. That makes a true unmangle impossible:

1. Parameters aren't free — __FiUc decodes to exactly (int, unsigned char), and unsigned char is the only type that mangles to Uc (typedef/const don't change that). So any naturally-mangled declaration must declare the 2nd param uchar.

2. A uchar param must narrow somewhere — GCC 2.95 will emit an andi …,0xff at a call site (or the callee). But the original has no narrowing instruction anywhere. Any insertion is a byte the original doesn't have → broken match. (That's the andi that killed the bif caller.)

3. Arguments can't rescue it either — to avoid the narrow you'd need the source value to already be a byte, but the original loads it as a word (lw a1,12(a2)). A uchar-typed field would compile that load as lbu instead → now you break the load rather than the call.

I don't really understand why, but the function cannot be unmangled