Re: [hatari-devel] 030 exceptions on auto-increment instructions

[Toni Wilen <twilen@xxxxxxxxxx>]

> While mailing about some issue I was hitting with m68k Linux, it
> was noticed that Linux fault handler gives different register
> values under Hatari than under real 030.
> 
> Faulting instruction is:
>     $00249f5a : 0e98 2000  moves.l   (a0)+,d2
> 
> A0 reg content is struct member offset address, but struct was NULL.
> 
> Under Hatari Falcon emulation, Linux fault handler reg dump showed A0
> value to be 0x04, whereas with under real 030 Mac it showed 0x08.

I guess this means CPU does increment (and pre-decrement, possibly even
flags are partially set at this point depending on instruction) before
MMU detects the fault and because MMU is not fully integrated to CPU
(like in 68040+. 68030 is basically 68020+68851+data cache integrated in
single package with reduced 68851 instruction set), it is MMU's task to
handle the exception logic which means there is only fault address that
needs to be known (source of address is irrelevant at this point) and
CPU only needs to know where to continue execution after RTE. 68030
continues after MMU fault, 68040+ restarts.

Current emulation can't handle this because whole instruction is retried
(with already executed memory writes skipped and already executed reads
returning "cached" values to simulate continuation). Most likely new
"68030 MMU continuation" CPU core would be needed to fully emulate this
behavior.

Fortunately this is undocumented behavior so no "normal" program should
care except perhaps some debugger like programs.