Aw: Re: [hatari-devel] 68000: Wrong order of bus accesses for move.l xx,-(Ay)

["Christian Zietz" <czietz@xxxxxxx>]

Hello Toni,

 

I will check CLR.L and NEG.L later today or tomorrow. I also expect them to behave the same. According to the Motorola patents -- which are considered to be fairly accurate -- CLR.L, NEG.L and NOT.L have exactly the same microcode, only the ALU is configured differently. (This also explains why CLR.L does a superfluous read access: the microcode reads the data, the ALU then performs some calculation on this data that always returns 0.)

 

Regards

Christian

 

Gesendet: Mittwoch, 31. Januar 2018 um 21:37 Uhr
Von: "Toni Wilen" <twilen@xxxxxxxxxx>
An: hatari-devel@xxxxxxxxxxxxxxxxxxx
Betreff: Re: [hatari-devel] 68000: Wrong order of bus accesses for move.l xx,-(Ay)

>>> Same for (an)+ addressing mode, some instructions probably have already
>>> added An by 2 before second word access.
>>
>> Can you propose some instructions to test? Same as above? As this is
>> quite a time-consuming process, it'll probably take a while until you
>> get results from me, though.
>
> OK, I now tested the same set of instructions like in my previous mail,
> but this time with the (An)+ addressing mode. Hope it helps.
>
> FA A6 FA A6
> Bus cycle First Second
> MOVE.L D0,(A6)+ 0 0 2 0
> MOVE.L (A6)+,D0 0 0 2 4
> MOVEM.L (A6)+,D0 0 0 2 0
> NOT.L (A6)+ 0 0 2 4
> Bus cycle Third Fourth
> NOT.L (A6)+ 2 4 0 4

Thanks. It confirms that are differences.

Read-modify-write instructions (NOT, AND, CLR, etc..) most likely use
same microcode bits for all memory access operations and should work
identically.

Could you check if CLR.L and for example NEG.L works exactly like NOT.L?

MOVEs and MOVEM variants most likely are unique..