Morten wrote:

> of course this might very well be purely academic, but the result is still
> incorrect regardless of how you turn it. ((0-0)+0+(c)) should never result
> in 1. as for whether you can work around it, that is a different question.
> but the fact is that the result is incorrect.

You're simply labouring under a misunderstanding of how carry flags work.
The only thing incorrect here is following SUBS with ADC. There is no
meaning to this instruction sequence.

Carry is only defined on ADD. SUB defines borrow, and borrow is mapped into
the C flag one of two possible ways. To say that ((0-0)+0+(c)) even has
*meaning* is to make an unwarranted assumption about how this mapping is
done. Carry and borrow are two distinct concepts, and to treat them as the
same in code is incorrect. It is your code that is wrong, *not* the CPU.

It's just like Damian said - it's an arbitrary choice like big-endian vs
little-endian. Except that there are some asm tricks that are possible in
little-endian that aren't possible in big-endian and vice versa. I *hoped*
I was going to learn something and find out that there's a trick you can do
in carry = borrow systems that you can't do in carry = !borrow systems, but
I fear I'm going to be disappointed. I wasn't meaning to debate this with
you, I just wanted to know if you had any use for that sequence or if it was
just a contrived example.

Jay wrote:

> I confirmed that this is does occur (at least in the VisualBoy emulator).

Oh right an EMULATOR gives a result that doesn't match the ARM docs and
that's confirmation of a problem with the ARM?! Gimme a break.

I agree that it's puzzling to find the carry flag set after Morten's first
sequence:

mov r10,#0x7f000000
mov r11,#0x1fc00000
adds r12,r10,r11,LSL #2

But I just tested it on an Acorn ARM machine and it doesn't. It gives C = 0
as you would expect. And C = 1 if you do LSL #3, again, as you would
expect.

Can anyone confirm Morten's result on an actual GBA?