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
After some discussion on the gbadev Discord server, it was found that pc has a "weird" behaviour when a bx instruction is executed to ARM state with a mis-aligned address (aka bit 1 set): while the CPU is able to "internally" align the address to fetch an instruction with correct alignment, on pc the bit1 keeps set, which can lead to miscalculations in any instruction that uses it as an operand (such as pc-relative loads and stores).
We can check the vaildity of this hypothesis with a very simple subroutine that gets the pc on such a state:
8001708: 46c0 nop @ (mov r8, r8)
800170a: 4778 bx pc @ this will branch to pc = 0800170e
800170c: e1a0000f mov r0, pc @ this will set r0 = mis-aligned pc: 08001716
8001710: e12fff1e bx lr
(the source file is like this)
.section .rom, "ax", %progbits
.type getMisalignedPC STT_FUNC
nop ; to ensure mis-alignment (with the .align 2 up there)
bx pc ; this instruction will fetch a pc whose set bit is 1
mov r0, pc ; this pc should be misaligned as well
(I tried to upload a GBA ROM here, but GitHub doesn't let me)
On the hardware (tested by @evanbowman), the returned PC is what is expected by the above hypothesis:
On mGBA, however, the returned PC is aligned to the lowest word (08001714), contradicting the result on hardware.
This aligns with what the ARM7TDMI Technical Reference says about bits 1 and 0 of pc on ARM state:
Whether or not instructions having pc as an operand will correctly use the "correct" (aligned) program counter value is not tested (though I doubt, since bl in Thumb sets bit 1 of lr).
The text was updated successfully, but these errors were encountered:
I'm pretty sure I correctly implemented part of this a few versions ago, but clearly not all of it. I'd have to dig through the log. It's related to some weirdness with an Emerald ACE payload misbehaving that merrp brought to my attention.
Can you upload the ROM zipped? You can't upload .gba files but you can upload .zip files with .gba files in them.
I think the specific issue is actually in the implementation of the Thumb BX instruction--I'm pretty sure the ARM BX instruction would work as intended here, but having an easy way to test would be much appreciated.