mulu.l (a0),d0-d1 on 68060

[BlankVector]

Hello.

Basically, it seems that WinUAE allows the "mulu.l (a0),d0-d1" instruction in 68060 mode, while it should not.

I bumped into this bug when running EmuTOS. It detects the presence of a 68060 CPU by testing that instruction. If it fails with an unimplemented instruction exception, it is assumed that the CPU is a 68060. If it works, the CPU is detected as 68040 (of course tests for other CPUs are done before).

I have no real 68060 myself to check the correct behavior. However, it is described in the official M68060 User's Manual. See page 366 in the PDF. It is said that mulu.l to 64-bit result is unimplemented (as well as a few other instructions) and triggers an unimplemented integer instruction exception.

For accurate 68060 emulation, the behavior should be the same in WinUAE.

[Toni Wilen]

It is by design.

Emulating unimplemented instruction exceptions 100% correctly is very complex and slow. Performance wins here. (This also includes FPU instructions)

"Compatible" 040/060 mode may be implemented in future.

[BlankVector]

Ok, no trouble.
In EmuTOS, I have changed the 68060 detection using "movec pcr,d1", now it works as expected on WinUAE too.

[Toni Wilen]

All MOVEC registers are 100% correctly emulated (including masking of unused bits) because they are very commonly used to detect CPU type.

Only exception (that don't cause exceptions) are instructions that 68020/030 (and/or 68881/68882) support but which were removed from 68040 or 68060.

[Toni Wilen]

68060 unimplemented integer instruction exception is supported in next beta. (If compatible CPU checkbox is set)

I forgot that only unimplemented FPU instructions need complex handling, integer instructions are easy.