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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 4/13/19 2:26 PM, Nicolas Pomarède wrote:
> Le 13/04/2019 à 01:08, Eero Tamminen a écrit :
> > 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.
> >
> > Environments weren't completely identical, so it's not 100% sure
> > this is WinAUE CPU core issue, but I think it warrants checking.
> >
> > If you can have recent Linux version (5.x or slightly older, with
> > SYSRQ config option enabled) under WinUAE and real m68k HW, this
> > is easy to trigger.  Just do:
> >      # echo t > /proc/sysrq-trigger
>
> hard to tell without the context of this instruction, what is the value 
> of SFC before the MOVES ?
>
> Something must be missing also, because if A0=0 before MOVES, then 
> "MOVES.L (A0)+,D2" can increment or not A0 before the exception trigger 
> (depending on the microcode order for this instruction, I didn't check).
>
> But in the end A0 will be either 0 or 4, but I don't see how it could be 
> 8, or it would mean that a 2nd (A0)+ instruction could be executed under 
> 030 Mac.

Struct was NULL, struct member offset was 4, so the pointer this
instruction got, was 0x4.  With .l increment, value should be 0x8
after executing the instruction once (but it page faults).


> It would be better to compare a real 030 falcon with Hatari (remember 
> that under Atari's the lowest 0x800 bytes of RAM require supervisor 
> access, maybe this makes a difference).


	- Eero