Solving the Mystery of ARM7TDMI Multiply Carry Flag
bmchtech.github.io
Solving the Mystery of ARM7TDMI Multiply Carry Flag
1–10 of 35 posts
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#2https://shonumi.github.io/blog/nds_rolling.html
More context on how this value affects (at least one) DS game- see post from December 27th, 2019.
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#3And just to get this out of the way, the carry flag’s behavior after multiplication isn’t an important detail to emulate at all. Software doesn’t rely on it.
On as fixed of a hardware as a game console, and with the accompanying anti-piracy/anti-cheating/emulation efforts of that industry, I'd expect it to be. From the history of emulating previous consoles, we know that any deterministic difference can and will be exploited, either to determine whether the hardware is authentic, or incidentally as a result of unintentional bugs.
This reminds me of the Z80, where two undefined flags resisted analysis for several decades; a 2-year-old set of slides on the state of that here: https://archive.fosdem.org/2022/schedule/event/z80/attachmen...
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#4https://shonumi.github.io/blog/nds_rolling.html More context on how this value affects (at least one) DS game- see post from December 27th, 2019.
I'm not really familiar with ARM Asm but do you think that's handwritten Asm that its author overlooked the effects of the carry and it just happened to work, or a clever "emulator trap" added by Nintendo's compiler?
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#5> Seriously, they decided that the program counter should be a general purpose register. Why???
Don't really understand this reaction. Why not? Seems to make for a nice regular design that the PC is just another register.
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#6And just to get this out of the way, the carry flag’s behavior after multiplication isn’t an important detail to emulate at all. Software doesn’t rely on it. On as fixed of a hardware as a game console, and with the accompanying anti-piracy/anti-cheating/emulation efforts of that industry, I'd expect it to be. From the history of emulating previous consoles, we know that any deterministic difference can and will be e…
While it’s a bit newer than the GBA, there is at least one Wii game with intentional anti-emulation measures:
https://tcrf.net/Cars_2_(PlayStation_3,_Xbox_360,_Windows,_W...
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#7> Seriously, they decided that the program counter should be a general purpose register. Why??? Don't really understand this reaction. Why not? Seems to make for a nice regular design that the PC is just another register.
The big issue is that it doesn't really need to be a GPR. You never find yourself using the PC in instructions other than in, say, the occasional add instruction for switch case jumptables, or pushes / pops. So it ends up wasting instruction space, when you could've had an additional register, or encoded a zero register (which is what AARCH64 does nowadays).
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#8> Seriously, they decided that the program counter should be a general purpose register. Why??? Don't really understand this reaction. Why not? Seems to make for a nice regular design that the PC is just another register.
Yeah, it was that way for all previous ARM processors too, for exactly that reason. Adding special cases would have increased the transistor count, for no great benefit.
The only downside was that it exposed internal details of the pipelining IIRC. In the ARM2, a read of the PC would give the current instruction's location + 8, rather than its actual location, because by the time the instruction 'took place' the PC had moved on. So if/when you change the pipelining for future processors, you either make older code break, or have to special case the current behaviour of returning +8.
Anyway, I don't like their reaction. What they mean is 'this decision makes writing an emulator more tricky' but the author decides that this makes the chip designers stupid. If the author's reaction to problems is 'the chip designers were stupid and wrong, I'll write a blog post insulting them' then the problem is with the author.
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#9And just to get this out of the way, the carry flag’s behavior after multiplication isn’t an important detail to emulate at all. Software doesn’t rely on it. On as fixed of a hardware as a game console, and with the accompanying anti-piracy/anti-cheating/emulation efforts of that industry, I'd expect it to be. From the history of emulating previous consoles, we know that any deterministic difference can and will be e…
In the GBA scene, people didn't actually tend to exploit the carry flag at all. If there was any anti emulation, it was usually flashcart related or cpu timing related.
Re: Solving the Mystery of ARM7TDMI Multiply Carry Flag
#10> Seriously, they decided that the program counter should be a general purpose register. Why??? Don't really understand this reaction. Why not? Seems to make for a nice regular design that the PC is just another register.
The big issue is that it doesn't really need to be a GPR. You never find yourself using the PC in instructions other than in, say, the occasional add instruction for switch case jumptables, or pushes / pops. So it ends up wasting instruction space, when you could've had an additional register, or encoded a zero register (which is what AARCH64 does nowadays).
But it is (or was originally) used in lots of places, not just jump tables, generally to do relative addressing, for example when you want to refer to data nearby, e.g.
ADD r0, r15, #200
LDR r1, [r15, #-100]
etc