Re: [hatari-devel] Possible bug in 060 exception stack frames

[Thorsten Otto <admin@xxxxxxxxxxx>]

On Sonntag, 17. Januar 2021 13:55:26 CET Thorsten Otto wrote:

> On Sonntag, 17. Januar 2021 13:35:10 CET Toni Wilen wrote:

> > AmigaOS 68060 support library (which is

> > also based on Motorola FPSP) emulates this instruction correctly.

>

> But have you ever run the test program there? I think using -(a7) or (a7)+

> in conjunction with mulu.l is rather unusual.

>

> >Does it work if addressing mode is not -(a7)?

>

> Yes, only -(a7) or (a7)+ crashes.

 

By adding a trace in op_unimpl, i get this output:

 

...

68060 unimplemented opcode 4C20, PC=0101c796, SP=01021c86
68060 unimplemented opcode 4C28, PC=0101c7e8, SP=01021c86
68060 unimplemented opcode 4C28, PC=0101c834, SP=01021c86
68060 unimplemented opcode 4C3C, PC=0101c884, SP=01021c86
68060 unimplemented opcode 4C3A, PC=0101c8d4, SP=01021c86
68060 unimplemented opcode 4C21, PC=0101c920, SP=01021c86
68060 unimplemented opcode 4C22, PC=0101c972, SP=01021c86
68060 unimplemented opcode 4C23, PC=0101c9c4, SP=01021c86
68060 unimplemented opcode 4C24, PC=0101ca16, SP=01021c86
68060 unimplemented opcode 4C25, PC=0101ca68, SP=01021c86
68060 unimplemented opcode 4C26, PC=0101cabc, SP=01021c86
68060 unimplemented opcode 4C27, PC=0101cb12, SP=01021cc6
...

The output is done before the exception frame is built. Opcodes 4c21-4c27 are mulu -(An),d2:d3 for n=1-7. Note how the SP suddenly changes for the last one.