Can someone explain why FF00 is stored in d1 after:
MOVE.W #$FFFF, d1
ADD.B #1, d1
I understand that a word is 16 bits in 68k architecture but was wondering why the result is FF00 rather than 00FF and what would change if MOVE.B
or MOVE.L
were used?
The
move.w
instruction places FFFF intod1.w
, which is the lower 16 bits of 32-bitd1
. The upper 16 bits are unaffected by this move, so without more information we can't say what's ind1
(d1.l
), but we know that we have XXXXFFFF ind1
(where the x's represent unknown).Because the
add.b
is a byte sized operation, it is adding tod1.b
, which is the lower 8 bits ofd1
. What's being added by that instruction is FF and 01. Mathematically that addition result is 0x100, however, as this is an 8-bit addition instruction, the result is truncated to 0x00 (condition codes are set if the program wants to know about overflow signed or unsigned). Added together and truncated to 8 bits, we get 00, and so the lower 8 bits ofd1
(akad1.b
) will hold 00. The 16 bits ofd1.w
will hold FF00, then because the FF part is unaffected by theadd.b
, and thus that part carries over from the prior value (set by themove.w
).The 32-bit register
d1
will hold XXXXFF00, where the XXXX is unknown as it comes from some code sequence prior and not shown.If
move.b
were used we then could not speak to the upper 24 bits of thed1
register, since they would be unaffected by the code sequence. The result would be xxxxxx00 in registerd1
, where x means don't know.If
move.l
were used we would know positively the full value of thed1
register: 0000FFFF would be the initial value after the move, and 0000FF00 the final value after theadd.b
.