|Re: [hatari-devel] 030 exceptions on auto-increment instructions|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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).