Thread: movep on 68060
View Single Post
Old 28 June 2016, 01:23   #1
BlankVector
Registered User
 
Join Date: Jun 2012
Location: Paris, France
Posts: 148
movep on 68060

This is the sequel of the issue I incorrectly reported there due to wrong diagnostic.

I was fooled by the WinUAE debugger.
It is actually related to movep on 68060.

Facts:

1) The failing program is DESKTOP.PRG (Tera Desktop). It fails on 68060 because it uses movep. And it is well known that movep is not supported on 68060.

2) I was fooled by the wrong WinUAE disassembly.
The actual opcode is "movep.l d1,-7(a1)".
WinUAE disassembles it to:
Code:
00035AFA 03c9 fff9                [ MVPRM.L D1,(A1, -$0007) == $007fcb1b ]
00035AFC fff9                     ILLEGAL
I assume that MVPRM.L means "MOVEP.L register to memory". So the first line is good. But the second one is completely bogus: instead of advancing 4 bytes, it only advances 2 bytes and repeats the operand of the previous instruction, disassembled to ILLEGAL.
At first glance, I didn't notice that the offset of the second line was only 2 bytes after the previous 4-byte instruction. So I thought that a spurious word was inserted, suspecting IDE trouble. Actually, the memory is right, but the disassembly is wrong.
This is a WinUAE disassembly bug, this should be fixed.

3) When "Unimplemented CPU emu" is checked, the program fails with "Illegal instruction". I didn't expect that, because as far a I understand that checkbox should have emulated the missing movep.
This looks like an incomplete missing instructions emulation, WinUAE should be fixed for that.

4) When "Unimplemented CPU emu" is not checked, it fails with an exception number 61 "Unimplemented Integer Instruction". I don't know if this is accurate or not, intuitively I would have expected a classic "Illegal Instruction Exception".

So the situation is quite clear now.
Toni, you can tell me what is going to be fixed, and what is not.
BlankVector is offline  
AdSense AdSense  
 
Page generated in 0.05217 seconds with 9 queries