I got fooled by address register word size operations

[mr.spiv]

I had a bug that haunted me for quite some time.. me and my stupid premature optimizations. Anyway, typically address register word size operations sign extend and stuff automatically to 32 bits. I tend to use that routinely. So, my code had:

SUBA.W A2,A2

in an attempt to clear A2 but if bits 31-16 contained data they remained and did not get sign extended to all 0 or 1 as I had assumed. Took a while to figure this out from the depths of macro mush and admit being caught pants down I had to run few more experiments and code like:

MOVE.L #$00AA0001,A0
MOVE.L #$00110002,A1
SUBA.W A1,A0

Produces #$00A9FFFF and not #$FFFFFFFF as I had expected. What confuses me is that #$00AA0001 in A0 does not seem to get sign extended to #$00000001 but apparently #$00110002 in A1 does get sign extended to #$00000002. What I am not seeing/knowing/understanding here?

[ross]

Is the source that is sign extended in Ax.w operations.

So this is like:

MOVE.L #$00AA0001,A0
MOVE.L #$00110002,A1
MOVE.W A1,A1
SUBA.L A1,A0

Yes, you could use MOVE.W Ax,Ax to sign extend Ax registers

This explain also the SUBA.W A2,A2

[mr.spiv]

Originally Posted by ross

Is the source that is sign extended in Ax.w operations.

Right.. I had to reread what the manual actually says and yes "Word-sized source operands are sign-extended to 32-bit quantities prior to the subtraction." Sigh, I have actually missed this detail all these years

[meynaf]

There is also the trick to use CMPA.W on same reg to check if a signed value fits in 16-bit (i.e. is between $ffff8000 and $00007fff).

[Photon]

SUB and CMP should use the exact same logic, cmp is sub without store. From memory there is no time gain (or loss of time loss ) for An as there is for Dn (on 68000) because of the extra operations (also includes ADD). I.e. if you go by 6c instead of 8c check footnotes.

move.l #$0ffffffff,a0
sub.w a0,a0
move.l #$ffff0fff,a1
sub.w a1,a1

a0=$10000000
a1=$ffff0000

SUB and SUBA -> SUBA instruction, according to AsmOne debugger. Is there a way to get a separate, different SUB <ea>,An opcode?

[a/b]

Nope, that specific mode/reg combo of sub is used to encode subx.

[Photon]

Originally Posted by a/b

Nope, that specific mode/reg combo of sub is used to encode subx.

OK, I was thinking of MOVEA. No diff there either? And flags unaffected?

Also, ADDA/ADD ea,An (and same for move) doesn't sign-extend according to Motorola.

(I'm only following through and being exhaustive.) So, only SUB and CMP.

But where there's an unusual behavior there could be a niche case to abuse for those two.

[a/b]

No difference on opcode level, each movea variant is using a unique opcode (there is no opcode duplication with move). Basically, it's all move $2xxx/$3xxx but if destination is an areg, move is changed to movea (to indicate different behaviour regarding ccr etc.). Move $1xxx (.b) to areg are all invalid (exception).

[mr.spiv]

Originally Posted by meynaf

There is also the trick to use CMPA.W on same reg to check if a signed value fits in 16-bit (i.e. is between $ffff8000 and $00007fff).

Ha, that was neat Never thought about that before. Maybe I find use for that some day.

[roondar]

This is certainly something I ran into as well. It's a good source for rather subtle bugs

[Photon]

Originally Posted by a/b

No difference on opcode level, each movea variant is using a unique opcode (there is no opcode duplication with move). Basically, it's all move $2xxx/$3xxx but if destination is an areg, move is changed to movea (to indicate different behaviour regarding ccr etc.). Move $1xxx (.b) to areg are all invalid (exception).

It's changed by what? Not the CPU, the Assembler. My comment was only regarding CPU legal, different opcodes that could have different or same behavior. For exploration (and exactness) since the question is already answered.

[meynaf]

Originally Posted by Photon

OK, I was thinking of MOVEA. No diff there either? And flags unaffected?

No flags affected by MOVEA, ADDA, SUBA. Only CMPA does.

Originally Posted by Photon

Also, ADDA/ADD ea,An (and same for move) doesn't sign-extend according to Motorola.

Are you sure Motorola documented that ? MOVEA and ADDA sure also do a sign-extend.

Originally Posted by a/b

Move $1xxx (.b) to areg are all invalid (exception).

If you like odd things : even though everything byte related is invalid if address regs are used, 020+ MOVES instruction isn't.

Originally Posted by Photon

It's changed by what? Not the CPU, the Assembler. My comment was only regarding CPU legal, different opcodes that could have different or same behavior. For exploration (and exactness) since the question is already answered.

It's changed by the cpu as well, if you consider MOVEA as a different operation compared to usual MOVE.
Because contrary to ADDA,SUBA,CMPA which all have specific opcodes, MOVEA occupies natural space where MOVE (to An) would be.

[bebbo]

Originally Posted by Photon

SUB and CMP should use the exact same logic, cmp is sub without store. From memory there is no time gain (or loss of time loss ) for An as there is for Dn (on 68000) because of the extra operations (also includes ADD). I.e. if you go by 6c instead of 8c check footnotes.

move.l #$0ffffffff,a0
sub.w a0,a0
move.l #$ffff0fff,a1
sub.w a1,a1

a0=$10000000
a1=$ffff0000

SUB and SUBA -> SUBA instruction, according to AsmOne debugger. Is there a way to get a separate, different SUB <ea>,An opcode?

a0 = $00000000


the sub.w a0,a0 uses a0.w sign extended
$ffff -> $ffffffff
$ffffffff - $ffffffff = $00000000


the word used in adda/suba is sign extended before a long add/sub is calculated

[Photon]

Originally Posted by meynaf

Are you sure Motorola documented that ? MOVEA and ADDA sure also do a sign-extend.

I'm sorry, it was mentioned a little later for both, in the opmode field. But testing it, here is something curious. MOVE sign extends, but ADD doesn't?

	move.l #$0000ffff,a0
	move.l #$0000ffff,a1
	add.w a0,a1			;a1=$0000fffe
	move.w a0,a2			;a2=$ffffffff

At least I've tried with different values and I can't make the upper word of a1 change at all.

Originally Posted by meynaf

It's changed by the cpu as well, if you consider MOVEA as a different operation compared to usual MOVE.
Because contrary to ADDA,SUBA,CMPA which all have specific opcodes, MOVEA occupies natural space where MOVE (to An) would be.

Maybe for the Debugger, but I mean changing the opcode from an imaginary existing move ea,An to movea ea,An. As in two different instructions in the CPU, one of them would then be in an unnatural space

[ross]

Originally Posted by Photon

But testing it, here is something curious. MOVE sign extends, but ADD doesn't?

This is like:

	move.l #$0000ffff,a0
        move.w a0,a0
	move.l #$0000ffff,a1
	add.l a0,a1			;a1=$0000fffe
	move.w a0,a2			;a2=$ffffffff

Nothing strange here

The arithmetic operations are always full 32bit as far as the Ax registers are concerned.

[Thomas Richter]

Originally Posted by Photon

I'm sorry, it was mentioned a little later for both, in the opmode field. But testing it, here is something curious. MOVE sign extends, but ADD doesn't?

Operations on Ax registers sign extend the source, not the destinatiion. That is, the left operand is extended, but not the target address register (that would not really make sense...).


For "movea" (not to be confused with "move" which does not take an address register as target), the left-hand operand is thus sign extended to 32 bit before performing the move. For "adda" (not to be confused with "add" which does not take an address register as target), the operand to be added is sign extended, but not the target to which it is added.


Likewise for suba (not "sub" which does not exist for address register targets).


That your assembler converts move to movea, sub to suba and add to adda is just a convenience function. The opcodes work differently. (sign extension just being one difference, setting flags being another).

[meynaf]

Originally Posted by Photon

At least I've tried with different values and I can't make the upper word of a1 change at all.

Try this then :

 move.l #$00007fff,a0
 move.l #$0000ffff,a1
 add.w a0,a1			; a1=00017ffe

[Photon]

Originally Posted by meynaf

Try this then :

 move.l #$00007fff,a0
 move.l #$0000ffff,a1
 add.w a0,a1			; a1=00017ffe

Hm. Well, source is unsigned so this doesn't really test it. But move.l #$ffff7fff,a0 gives the same result, so I'm convinced.

adda.w sign extends source and performs a full 32-bit add.

[meynaf]

Originally Posted by Photon

Hm. Well, source is unsigned so this doesn't really test it. But move.l #$ffff7fff,a0 gives the same result, so I'm convinced.

adda.w sign extends source and performs a full 32-bit add.

If you want to see all effects at once :

 move.l #$55558888,a0
 move.l #$11111111,a1
 adda.w a0,a1           ; a1=$11109999