Solving the Mystery of ARM7TDMI Multiply Carry Flag

Post by DevilStuff » Wed, Oct 23, 2024, 6:08 AM UTC

joosters wrote: post #8

ujikoluk wrote: post #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.

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 h…

Post by DevilStuff » Wed, Oct 23, 2024, 6:11 AM UTC

joosters wrote: post #10

DevilStuff wrote: post #7

Earlier quoted context omitted.

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

Post by joosters » Wed, Oct 23, 2024, 6:34 AM UTC

DevilStuff wrote: post #11

joosters wrote: post #8

Earlier quoted context omitted.

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 h…

Hey, I'm the author, sorry it came off that way, I was really just poking fun. I should've definitely phrased that better! But no, I really think that making the program counter a GPR isn't a good design decision - there's pretty good reasons why no modern arches do things that way anymore. I admittedly was originally in the same boat when I first heard of ARMv4T - I thought putting the PC as a GPR was quite clean, b…

Post by f1shy » Wed, Oct 23, 2024, 6:49 AM UTC

userbinator wrote: post #3

And 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…

Post by DevilStuff » Wed, Oct 23, 2024, 6:56 AM UTC

immibis wrote: post #16

DevilStuff wrote: post #13

Earlier quoted context omitted.

Ah I miscommunicated, I still think PC can and should be used in places like the operand of an LDR / ADD. It's using it as the output of certain instructions (and allowing it to be used as such) that I take issue with. ARMv4T allowed you to set PC as the output of basically any instruction, allowing you to create cursed instructions like this lol: eor pc, pc, pc

Isn't writing to it except by a branch instruction undefined behaviour? If you can use it as an operand, it has a register number, so you can use it as a result, unless you special-case one or the other, which ARM didn't do because it was supposed to be simple. They could have ignored it by omitting some write decode circuitry, but why?