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
I saw a GtEscape build crashing on ArcEm, Arculator and ArchiEmu but only when configured for ARM2, not ARM250. In fact it locked the virtual machines solid. After some digging I found that the OSLib that I link against isn't 26/32-bit neutral. The 32-bit version uses MRS instructions and they somehow work on emulated ARM250's, but not on emulated ARM2's.
The text was updated successfully, but these errors were encountered:
So OSLib uses the sequence RSB R0,PC,PC:MRS R0,CPSR which is intended to be 26/32-bit neutral, but happens to fail on ARM2 only. It uses that sequence to return CPU flags from os_read_mode_variable(). RSB R0,PC,PC isolates the flag bits on 26-bit ARM. MRS R0,CPSR fetches the flags register on 32-bit ARM. On ARM2 the MRS is UNDEFINED and will fault, but on ARM250/ARM3 it's a NOP.
So since it's a NOP and I don't care about the value returned, the build wobbles on unaware on ARM250+.
A hacky solution would be to physically NOP out that MRS.
The likely fix is to use _swi() and dodge OSLib's problematic os_read_mode_variable() veneer. However, we then discover that TimerMod also uses MRS so it can't be ARM2 compatible, despite my fixes... I must have tested it on ArcEm's default configuration which seems to be an ARM2aS, not an ARM2.
I saw a GtEscape build crashing on ArcEm, Arculator and ArchiEmu but only when configured for ARM2, not ARM250. In fact it locked the virtual machines solid. After some digging I found that the OSLib that I link against isn't 26/32-bit neutral. The 32-bit version uses MRS instructions and they somehow work on emulated ARM250's, but not on emulated ARM2's.
The text was updated successfully, but these errors were encountered: