PS2: SN ProDG custom assembler issues

[IWILLCRAFT-M0d]

First thing I want to say, excuse my ignorance over these compilers, assembler and assembly ignorance in advance, I hope everything here I will say doesn't get misunderstood, and thanks for the patient if this get solves.

As I have been reporting in the PS1/2 Decomp server and something pointed out by @Mc-muffin, SN compilers contains an alternative assembler to the one from GNU which can be enabled by using -snas in the compilation, this assembler is important as it runs into an issue related with GP_REL (you can see the bug in action here, by removing -snas from the compiler arguments) which is important to match and for some other issue I will explain below, the problem is that this assembler runs in many issues with Splat and the INCLUDE_ASM macro, just few of them I noticed are:

• Neither macros.inc nor labels.inc works by default.
• • the usage of .size macro in glabel for some reason causes the assembler to suddenly crash without making any input about the error
• • the syntax of nonmatching macro is incompatible with the one that the assembler uses
• The assembler bundled in the 2.0 release of the SN SDK it runs into not generating one pad in loops, something that both the default GAS and modern binutils do
• • Here it is an example, the game which this function was extracted from uses version 2.95.3 (v1.36), but the assembler bundled with that release is generating an additional pad which also get generated when building the compiler output to object https://decomp.me/scratch/4BvBh
• • This even affect INCLUDE_ASM macro
• This assembler don't handle c1 macro instead it should be using cop1

There are two more I noticed, but didn't delve into them too much

• The usage of vadda.xyz have the input register inverted. The only instance where I have seen this splats generates vadda.xyz ACC, $vf0, $vf1 in the assembly, however, this assembler swapped the register, and instead it needs to be vadda.xyz ACC, $vf1, $vf0 otherwise it will generate a mismatching result
• Some instances where a GP_REL macro could be generated runs into issues. For now the only two instances I found of this bug are this:

    /* 8AE4 00107AE4 01000224 */  addiu      $2, $0, 0x1
    /* 8AE8 00107AE8 4000A397 */  lhu        $3, 0x40($29)
    /* 8AEC 00107AEC B48182AF */  sw         $2, (D_0044C8A4) /* gp_rel: (D_0044C8A4) */
    /* 8AF0 00107AF0 92EB83A7 */  sh         $3, (D_00453280 + 0x2) /* gp_rel: (D_00453280 + 0x2) */
    /* 8AF4 00107AF4 4500023C */  lui        $2, %hi(D_00453A80)

    /* 8E28 00107E28 01000224 */  addiu      $2, $0, 0x1
    /* 8E2C 00107E2C 2001A397 */  lhu        $3, 0x120($29)
    /* 8E30 00107E30 B88182AF */  sw         $2, (D_0044C8A8) /* gp_rel: (D_0044C8A8) */
    /* 8E34 00107E34 94EB83A7 */  sh         $3, (D_00453280 + 0x4) /* gp_rel: (D_00453280 + 0x4) */

In both of these instances the assembler has thrown me these errors:
Error : Assembler does not have AT register available, " sh $3, (D_00453280 + 0x2)"
Error : Assembler does not have AT register available, " sh $3, (D_00453280 + 0x4)"
And the process finishes with this message:
ee-gcc2953.exe: Internal compiler error: program ps2eeas got fatal signal 22
There may be more errors I missed, but I got stuck trying to solve this last issue

Not sure if this is just sad (because why these issues have to exist dang it) or fortunately (as there is only one public decomp which have run into this issue so still early to fix this before more decomps which runs into this issue join in) the only decomp for now running into all this issues (excepting the second one which is actually what I thought was related to the short loop bug I mentioned here, but I'm still setting up that one privately) is Dog's Life. The way that this assembler issue has been circumvented there is by marking as NON_MATCHING any function that requires the assembler to match and in matching build inserting the function using INCLUDE_ASM it compiles with GNU assembler instead, so this way progress keep being tracked, while it still able to make a building match, something like the latest PSX decomps, but if almost all functions that are actually matched were marked as NON_MATCHING until they finish a whole TU.

[IWILLCRAFT-M0d]

A mini update on the topic:

• Found out that the assembler don't handle local directive when defining symbols and instead it uses lsym
• The last issue I mention previously ocurrs specifically due to the lack of support of symbol + offset when using the GP register

At this point I don't know if this should be taken as an issue for Splat, as this seems to be more a thing to be considered for a tool like maspsx but focusing on this assembler, casually the last issue I previously mentioned also happens on old versions of ASPSX

[AngheloAlf]

Hi!
Sorry that you have found so many issues with this PS2 game. PS2 projects are a lot less mature than PS1 and N64 ones.

Just to be clear, the compiler you are using is SN GCC with SN AS, right? The scratched you linked has both "EE GCC 2.95.3 (SN BUILD v1.36)" and "EE GCC 2.95.3 (SN BUILD v1.14)".

macro.inc and labels.inc

• the usage of .size macro in glabel for some reason causes the assembler to suddenly crash without making any input about the error

Does removing .size fixes glabel? Or are other changes needed?

• the syntax of nonmatching macro is incompatible with the one that the assembler uses

What is the syntax that the assembler uses? Ideally we could adapt the macro to match what this assembler wants.

Pad loops

• The assembler bundled in the 2.0 release of the SN SDK it runs into not generating one pad in loops, something that both the default GAS and modern binutils do

• • Here it is an example, the game which this function was extracted from uses version 2.95.3 (v1.36), but the assembler bundled with that release is generating an additional pad which also get generated when building the compiler output to object https://decomp.me/scratch/4BvBh
• • This even affect INCLUDE_ASM macro

Sounds like you are getting a mismatch with the generated assembly from the compiler.
If that's the case, then there's nothing we can do about it. You would need to find the correct compiler/assembler or a patcher tool like maspsx.

Instruction syntax differences

• This assembler don't handle c1 macro instead it should be using cop1

I see. That sucks, I guess we can special case this behavior.
rabbitizer uses c1 for a very specific hack about a kinda broken sqrt.s syntax.
PS2 MIPS assembly is kinda broken. idk what Sony was doing...

• The usage of vadda.xyz have the input register inverted. The only instance where I have seen this splats generates vadda.xyz ACC, $vf0, $vf1 in the assembly, however, this assembler swapped the register, and instead it needs to be vadda.xyz ACC, $vf1, $vf0 otherwise it will generate a mismatching result

Oh, for real? That really sucks...
That's actually a lot harder to workaround. I'll need to investigate a lot more.
In the meanwhile, could you post a scratch or an assembly snippet where this happens, please?

GP REL

• Some instances where a GP_REL macro could be generated runs into issues. For now the only two instances I found of this bug are this:

  /* 8AE4 00107AE4 01000224 / addiu $2, $0, 0x1
  / 8AE8 00107AE8 4000A397 / lhu $3, 0x40($29)
  / 8AEC 00107AEC B48182AF / sw $2, (D_0044C8A4) / gp_rel: (D_0044C8A4) /
  / 8AF0 00107AF0 92EB83A7 / sh $3, (D_00453280 + 0x2) / gp_rel: (D_00453280 + 0x2) /
  / 8AF4 00107AF4 4500023C */ lui $2, %hi(D_00453A80)

  /* 8E28 00107E28 01000224 / addiu $2, $0, 0x1
  / 8E2C 00107E2C 2001A397 / lhu $3, 0x120($29)
  / 8E30 00107E30 B88182AF / sw $2, (D_0044C8A8) / gp_rel: (D_0044C8A8) /
  / 8E34 00107E34 94EB83A7 / sh $3, (D_00453280 + 0x4) / gp_rel: (D_00453280 + 0x4) */

In both of these instances the assembler has thrown me these errors: Error : Assembler does not have AT register available, " sh $3, (D_00453280 + 0x2)" Error : Assembler does not have AT register available, " sh $3, (D_00453280 + 0x4)" And the process finishes with this message: ee-gcc2953.exe: Internal compiler error: program ps2eeas got fatal signal 22

This is annoying.
I guess we could try to implement some logic in spimdisasm to handle this kind of issue.
In the meanwhile, you could manually define those symbols to avoid using the addend (i.e. define D_00453282 and D_00453284).
btw, how does the D_00453280 and D_00453280 look like?

Misc

• Found out that the assembler don't handle local directive when defining symbols and instead it uses lsym

splat doesn't care much about symbol visibility, it just uses whatever the user gives.

[IWILLCRAFT-M0d]

Sorry that you have found so many issues with this PS2 game. PS2 projects are a lot less mature than PS1 and N64 ones.

No need to be sorry, this is kind of expected, specially when tooling come up with this kind of quirks and this project are less common than they appear

Just to be clear, the compiler you are using is SN GCC with SN AS, right? The scratched you linked has both "EE GCC 2.95.3 (SN BUILD v1.36)" and "EE GCC 2.95.3 (SN BUILD v1.14)".

Yeah, however this applies to any SN SDK as they all come bundled with this alternative assembler (PS2EEAS.EXE)

Does removing .size fixes glabel? Or are other changes needed?

Yeah only that is needed to fix it

What is the syntax that the assembler uses? Ideally we could adapt the macro to match what this assembler wants.

I don't know actually

Sounds like you are getting a mismatch with the generated assembly from the compiler.
If that's the case, then there's nothing we can do about it. You would need to find the correct compiler/assembler or a patcher tool like maspsx.

This is not something of the compiler, as I previously said this is an issue of the assembler, and is an issue that even spread to the INCLUDE_ASM macro, in those cases the compiler just insert the functions through a .include macro with the path of the assembly file, I know now that this goes beyond any of you as I said in my previous message to yours

At this point I don't know if this should be taken as an issue for Splat, as this seems to be more a thing to be considered for a tool like maspsx but focusing on this assembler

Btw, @mkst mentioned in Discord that this behaviour in particular is derivative of the assembler ignoring .set noreorder, didn't fully understand what they meant, but I wanted to mention that

Oh, for real? That really sucks...
That's actually a lot harder to workaround. I'll need to investigate a lot more.
In the meanwhile, could you post a scratch or an assembly snippet where this happens, please?

I don't have the code at hand now, but even then is actually easy to patch out, I just did something like what the Sly 1 decomp does for avoiding the short loop bug by replacing the instruction with a .word macro and the hexadecimal value of the instruction, I think splat already does that for some macros?

This is annoying.
I guess we could try to implement some logic in spimdisasm to handle this kind of issue.
In the meanwhile, you could manually define those symbols to avoid using the addend (i.e. define D_00453282 and D_00453284).

Yeah exactly that's what I did and solve it, curiously this issue only ocurred with that variable in only two splits from the entire code and this is in the Dog's Life setup, I didn't run into this issue with the private setup I'm doing.

btw, how does the D_00453280 look like?

Didn't checked before fixing the issue, but I'm pretty much sure it may look like an array of shorts/s16

splat doesn't care much about symbol visibility, it just uses whatever the user gives.

This is actually conflicting a little, as this directive isn't supported by modern GNU so if apply it and I want to use --make_full_disasm_for_code then I'm fucked unless I touch macro.inc a little so whenever it detect it, it uses local instead

Yet again at this point I feel someone should rather do a tool in the same line as MASPSX, I initially though it was Splat fault, but as I started digging and getting help by people at PS Decomp discord I just further realized this thing is an issue of the assembler so a lot of tricks may need to be done to figure out this and make it work, the only thing I guess Splat can do is to make an option to make Spimdisasm don't generate symbol + offset

Btw I manage to get this assembler to fully compile and match in Dog's Life and with this solution also worked with the private repo I'm working (although I hit another wall with the .lsym not being supported by GAS)
IWILLCRAFT-M0d/dogcomp@c137bf1#diff-4d5f3192809ec1b9add6b33007e0c50031ad9a0a2f3f55a481b506468824db2c