You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that vmmul inexplicably flips the 2nd bit of it's rs parameter. As documented here and here. I'm fairly certain based on the psptoolchain patch, that it's the only instruction that has this anomaly, but who knows - maybe there's some other hidden oddities some where.
I figured you'd want to know, so you can update the documentation. 🙂
The text was updated successfully, but these errors were encountered:
Yeah we should clarify that!
The bit flip makes the rs parameter transposed (so M->E or E->M), right? That is due to the fact that the vmmul instruction does not actually multiply matrices (in the way that math defines it) but rather performs N*N vdot operations. The operations follow the same direction for both inputs, so this gives rs^T * rt (if I recall correctly). Therefore we "correct" the input to a more natural operation. This is indeed not very clear :P (However the pseudocode is correct and is tested correctly, since a direct encoding, using .word, is used, this is done to avoid binutils bugs).
I think more instructions existed in the official SDK, like vcmmul and vrmmul, variants that reorder registers and/or transpose matrices.
I will update the docs by adding some comment to explicitely mention that the "rs" register will be mangled by the assembler, since this is what we always did for binutils.
Thanks!
It appears that
vmmul
inexplicably flips the 2nd bit of it'srs
parameter. As documented here and here. I'm fairly certain based on the psptoolchain patch, that it's the only instruction that has this anomaly, but who knows - maybe there's some other hidden oddities some where.I figured you'd want to know, so you can update the documentation. 🙂
The text was updated successfully, but these errors were encountered: