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 into d1.w, which is the lower 16 bits of 32-bit d1. The upper 16 bits are unaffected by this move, so without more information we can't say what's in d1 (d1.l), but we know that we have XXXXFFFF in d1 (where the x's represent unknown).
Because the add.b is a byte sized operation, it is adding to d1.b, which is the lower 8 bits of d1. 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 of d1 (aka d1.b) will hold 00. The 16 bits of d1.w will hold FF00, then because the FF part is unaffected by the add.b, and thus that part carries over from the prior value (set by the move.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 the d1 register, since they would be unaffected by the code sequence. The result would be xxxxxx00 in register d1, where x means don't know.
If move.l were used we would know positively the full value of the d1 register: 0000FFFF would be the initial value after the move, and 0000FF00 the final value after the add.b.