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

[TheOnlyZac]

When 545u says unmangle the name here, I believe they just mean drop the __FiUc from the name. But I think we're getting at the real problem, which is the declaration of SetAMRegister in sound.h.

// The symbol's GCC2 mangling says (int, unsigned char), but the ROM call
// sites pass the second argument as a plain word with no narrowing, so the
// in-game declaration must have taken ints; bind by literal symbol name.
extern "C" void SetAMRegister__FiUc(int n, int bReg);

This cannot be faithful to the original source code, and it's illogical to say it "can't be unmangled"; the fact that we have debug symbols with mangled function signatures is evidence that there is a canonical, original signature that the compiler mangled to produce the symbols.

Keep in mind we use the debug symbols from the May prototype as hints, but the code changed between May and September so the mangled function name might not be accurate indicator of the parameter types in the final build, which we are targeting. So the goal isn't really to "unmangle" it to get the signature, but rather to holistically figure out what the signature is supposed to be based on the code.

[TheOnlyZac]

Hi again @lindskogen, thank you for the PR and I appreciate you wanting to push our progress forward with all the new function matches. Unfortunately the code has a many small problems and will require a lot of clean up before merging. I would ask that you please make any requested changes yourself and not have the AI do it, as it appears the model doesn't fully understand the project and is getting stuck in problematic loops.

I am going to continue making review comments until I have gotten through all the changes. Then in the interest of getting this merged as soon as possible, I will also lend a hand when I have time, so please make sure to pull any commits I make before working on it yourself. Also please refrain from adding any new code until we wrap up this PR.

[TheOnlyZac]

Ok, I've done my first pass and I noticed the vast majority of issues with the code fall into one of four categories:

1. Unnecessarily separation of a variable declaration from its definition and use
2. Nested if statements that can be combined with &&
3. Functions definitions marked as extern "C" that should be C++
4. Using repeated if statements to set a variable where the ternary operator could be used

There's a few other common quirks, but these cover a majority of my comments.

What will really take the most time to fix, I think, is that whenever the model got an undefined reference error while matching a function, it just defined whatever data/function was missing directly above the function body.

We will have to go through each one and determine where to move the relevant data/function declaration to. I'm open to suggestions as for the logistics of that.

[TheOnlyZac]

(fClosed == 0) —> (!fClosed)

[TheOnlyZac]

Why are these extern "C"?

[TheOnlyZac]

What are these and why are they extern C?

[TheOnlyZac]

Please re-add the deleted comments

[TheOnlyZac]

This file is too complex for me to fully review in this first pass, just leaving this note so we can circle back on it later.

[TheOnlyZac]

No extern C

[TheOnlyZac]

Delete, should be global data

[TheOnlyZac]

Delete

[TheOnlyZac]

Merge if conditions

[lindskogen]

@TheOnlyZac soo I might be fully gaslit by the AI by now, but your suggestions of merging the if statements and introducing ternaries in a few places made it not match anymore. And when I asked claude why, the answer was that gcc would optimize it differently..

I could try to split up the PR to make it less of a pain to review, just say the word.

[lindskogen]

There! I got a bunch of comments resolved!

Some notes:

• UNALIGNED_INT is load bearing and is needed to reproduce a unaligned store in FUN_001ddb20.
• nullptr doesn't exist in GCC 2.95.
• Merging some if-statements with && and ternaries broke the match since it was now optimized differently.

Lets work on this together! Hoping this helps!

[TheOnlyZac]

• UNALIGNED_INT is load bearing and is needed to reproduce a unaligned store in FUN_001ddb20.
• nullptr doesn't exist in GCC 2.95.
• Merging some if-statements with && and ternaries broke the match since it was now optimized differently.

• Sorry I don't remember asking about UNALIGNED_INT or FUN_001ddb20 specifically, what are you referring to?
• You're right, I wrote nullptr in a few of my comments where I should have wrote NULL
• I see, I didn't think anywhere I commented that would change the asm, but I might have been mistaken. Could you give me an example of where you tried to change it and it broke the match?

Also, again I would ask you to please stop using AI to edit the code, as it is creating more problems.

[TheOnlyZac]

Second pass of just the files changed since my last review (it's a lot more of the same). I realized I've been using the word "definition" a lot when I really mean "initialization", so be aware of that.

[TheOnlyZac]

No extern C

[TheOnlyZac]

Let's either make sure these are in the correct order in the header, or add a @todo comment to come back and do that later

[TheOnlyZac]

No extern C

[TheOnlyZac]

No extern C

[TheOnlyZac]

No extern C

[TheOnlyZac]

Put curly braces on new lines

[TheOnlyZac]

Try and declare i when setting up the loop

[TheOnlyZac]

Try merging decls

[TheOnlyZac]

Delete

[TheOnlyZac]

Delete