Is this a bug in EASy68K?

[sparhawk]

When writing a function I stumbled on this, and did a small test to confirm:

    move.l  #$abababab,d1
    movem.w d1,-(sp)
    movem.w (sp)+,d1            ; d1 now contains $ffffabab

I haven't tested it yet on WinUAE or real machine, as I don't have access at the moment, and now I wonder if this is a bug in EASy68k or not? I thought it would be legal to save only a word operand on the stack?
According to the M6800PRM.pdf this would be legal, so I assume a bug.

[a/b]

(Second, mem to reg) movem.w automatically sign-extends registers to longwords.

[DanScott]

Yes, word reads from stack to register are sign extended to a long

[meynaf]

movem.w from memory to registers always sign extend (this can actually be useful).
If you want to restore only a word operand, use move instead of movem.

[Cyprian]

interesting finding.

never heard before about data register sign extension.

[Kalms]

For your reference, the M68000PRM states on page 4-128 in the MOVEM description:

Moves the contents of selected registers to or from consecutive memory locations starting at the location specified by the effective address. A register is selected if the bit in the mask field corresponding to that register is set. The instruction size determines whether 16 or 32 bits of each register are transferred. In the case of a word transfer to either address or data registers, each word is sign-extended to 32 bits, and the resulting long word is loaded into the associated register.

[Antiriad_UK]

This was one of the tricks that I was really pleased to learn when relearning last year. I went through a load of routines stripping out ext.l used after a movem

[DanScott]

Don't think I ever actually used an ext.l after a movem ever... but it's a handy trick to know for any future implementations

[ross]

I organize everytime my data for movem access (both .w or .l).
And sign extension on data registers is usually usefull.

There a case I've also used movem to a single dx register, just to have not CPU flags set
(yes, a little slow, but with only worst alternatives available..)

[movem exist also for no register at all encoding, like

movem.l -(sp)

->

$48e7,$0

]

[sparhawk]

Originally Posted by ross

[movem exist also for no register at all encoding, like

movem.l -(sp)

->

$48e7,$0

]

And what does this do? Only decrement stack?

[ross]

Originally Posted by sparhawk

And what does this do? Only decrement stack?

Absolutely nothing (apart the 8 cycles for the two memory accesses on 68k, flags, stack and sp value sre untouched).
The only use that comes to mind is for some ugly SMC code, that varies registries selection based on value set on 2nd opcode instruction.

Well, forget about it

[ross]

Speaking of Easy68k I found two flaws, if someone is registered on their forum it could report the problem.

1.
(and this is big..)

  movea.l #$00800001,a5
  lea (a5,a5.l),a5

it completely fail to calculate final value for A5 because only 24 bits is maintained in result.
So at the end A5=$2..

2.

    btst    #0,d0

wrongly reported as 6 cycles instead of 10 (like other bit instructions).


Anyway I've a doubt about bit instructions and my manual is not clear about it..

instruction  size            dynamic                 static
                        register   memory       register   memory	
BCHG         byte          -       8(1/1) +        -       12(2/1) +
             long        8(1/0) *    -          12(2/0) *     -
BCLR         byte          -       8(1/1) +        -       12(2/1) +
             long       10(1/0) *    -          14(2/0) *     -
BSET         byte          -       8(1/1) +        -       12(2/1) +
             long        8(1/0) *    -          12(2/0) *     -
BTST         byte          -  	   4(1/0) +        -        8(2/0) +
             long        6(1/0)      -          10(2/0)       -

	+ add effective address calculation time
	* indicates maximum value

Is indicated in * which is a maximum value.
But I've not found where is it specified what affects this maximum value.

[Toni Wilen]

what affects this maximum value

Bits number larger than 15: instruction becomes 2 cycles slower.

[ross]

Originally Posted by Toni Wilen

Bits number larger than 15: instruction becomes 2 cycles slower.

Thanks Toni, another thing to keep in mind when optimizing 68k code.



EDIT
Another important thing to remember: if possible use logical operations directly, that are faster.
As it is very probable that bxxx instructions are microcoded, internally are fluxed to the basic operations in ALU.

This also explains why bclr is slower:
bchg -> set, eor
bset -> set, or

bclr -> set, not, and