movem bug in 68020+ modes?

[agranlund]

Admittedly a very rare case but it appears Hatari is not emulating a specific use of movem correctly in 68020+ modes
Caught me a bit off-guard when trying to get some code going on real hardware after working in Hatari.

movem.x rl,-(an)
There is a difference if the register used in predecrement mode is also contained in the register list.
For the 68020, 68030 and 68040 the value written to memory is the initial register value decemented by the size of the operation.
The 68000 and 68010 write the initial register value (not decremented).

--Cheers,
Anders

[Cyprian]

do you mean "movem.l A0,-(A0)"?

Attached you can find my test program and TT shows me:

20230914_232211.jpg

and Hatari:

grab0002.png

I've just sent that report to the Hatari team.

[mrbombermillzy]

Good spot.

[ThorstenOtto]

Interesting. But what exactly is the ´size of the operation´? Ie when you do a

Code: Select all

movem.l a0-a3,-(a3)

Then a3 will be saved first. Will the saved value be original value -4, or original value - 16?

[agranlund]

Interesting. But what exactly is the ´size of the operation´? Ie when you do a

Code: Select all

movem.l a0-a3,-(a3)

Then a3 will be saved first. Will the saved value be original value -4, or original value - 16?

It's the .l or .w so should be -4 for movem.l (regardless where the register appears in the register list)

[npomarede]

Hi
what Hatari version are you using for your test ? When using Hatari devel version, this case is correctly suported :

STF :
A0 before: 0000F55E
Saved value: 0000F55E

TT :
A0 before: 000167E8
Saved value: 000167E4

Nicolas

[Cyprian]

Hi
what Hatari version are you using for your test ? When using Hatari devel version, this case is correctly suported :

STF :
A0 before: 0000F55E
Saved value: 0000F55E

TT :
A0 before: 000167E8
Saved value: 000167E4

Nicolas

the issue was reported based on yesterdays build from there: http://antarctica.no/~hatari/latest/windows/

Today's build shows me:

Hatari_TT_Issue.png

[npomarede]

I see you're using "MMU", which I don't by default.
If I use MMU too, then the movem bug is reproducable.
I will have a look at the CPU tables used in MMU mode, maybe sthg is not correctly setup in Hatari for this mode.

Nicolas

[Cyprian]

ok, I've unchecked the MMU and the result was ok

[Eero Tamminen]

ok, I've unchecked the MMU and the result was ok

What if you keep MMU enabled, but disable cycle exact "(CE)" and prefetch "(PF)"?

(MMU emu works OK with Linux without them, but breaks when either cache or prefetch emulation is enabled.)

[Cyprian]

ok, I've unchecked the MMU and the result was ok

What if you keep MMU enabled, but disable cycle exact "(CE)" and prefetch "(PF)"?

(MMU emu works OK with Linux without them, but breaks when either cache or prefetch emulation is enabled.)

no change, the same issue.

I'll wait for antarctica build with Andreas' todays patch

[npomarede]

Hatari's source have been updated with patch from WinUAE.
Results are now correct when using MMU.

Nicolas