[hatari-devel] Re: 040/060 emulation issue with Q2

[Douglas Little <doug694@xxxxxxxxxxxxxx>]

...cont'd.

Two of the fault cases throw illegal instructions on FPU opcodes, within valid code.

$00028018 : f200 1400                          fmove.x   fp5,fp0

$0002801c : f210 4500                          fmove.s   (a0),fp2

$00028020 : f29b                               DC.W      $f29b

$00028074 : f200 083a                          ftst.x    fp2,fp0

$00028078 : f29d                               DC.W      $f29d

$0002807c : f200 1528                          fsub.x    fp5,fp2

$00028080 : f201                               DC.W      $f201

$00028084 : f201                               DC.W      $f201

$00028088 : 2081                               move.l    d1,(a0)

$0002808a : f23c 4538 4020 0000                fcmp.s    #$40200000,fp2

$00028092 : f29d                               DC.W      $f29d

$000280ce : f201                               DC.W      $f201

$000280d4 : ff70                               DC.W      $ff70  <-- illegal?

On 3 March 2015 at 18:27, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

I seem to be running into obscure emulation problems with a current project using the latest Hatari. None are timing related, or even involve the DSP. This occurs in normal Falcon 030 emulation mode.

The first involved some GCC inline assembler fragments, performing endian swaps on words/longs. The actual problem is probably with one of the fragments, register clobbers etc. Strangely it always gets stuck in a loop in the new Hatari, but runs correctly in older versions of Hatari or real HW. Disabling the asm optimizations allowed this area of the code to execute properly. Hmmm!

I'll investigate later what was up with the asm fragments, but it's a bit worrying :)

The second problem I ran into immediately after fixing the first. Some plain C code is looking up a game object from a table, and performing a function pointer call. No assembly involved. This part of the code always worked on previous versions of Hatari, and on real HW. It also compiles and works properly in VisualStudio 8. 

On the latest Hatari, this code is jumping to address 0 for one of the game objects.

Again, it could be some sort of code bug that hasn't shown itself until now - maybe. However getting two of these in a row - for the first time - without any DSP stuff being involved is suspicious. Especially so that the same binary runs happily in Hatari 1.7.

I noticed in both cases some 030 addressing modes were involved. e.g. see below.

In the earlier case, FPU code was mixed with CPU code (but not used to affect conditions/branches - just to convert data).

If I find out more detail I'll update...

_Object_Init:

$00026ea8 : 2f02                               move.l    d2,-(sp)

$00026eaa : 202f 0008                          move.l    8(sp),d0

$00026eae : 2400                               move.l    d0,d2

$00026eb0 : e58a                               lsl.l     #2,d2

$00026eb2 : 2200                               move.l    d0,d1

$00026eb4 : ef89                               lsl.l     #7,d1

$00026eb6 : 9282                               sub.l     d2,d1

$00026eb8 : 2230 19b0 0034 2430                move.l    $342430(d1.l),d1  <- d1 is garbage by this point. uncommon addressing mode.

>

$00026ec0 : 2401                               move.l    d1,d2

$00026ec2 : e78a                               lsl.l     #3,d2

$00026ec4 : eb89                               lsl.l     #5,d1

$00026ec6 : 2242                               movea.l   d2,a1

$00026ec8 : 2071 1930 0011 767c                movea.l   $11767c(a1,d1.l),a0

$00026ed0 : 241f                               move.l    (sp)+,d2

$00026ed2 : 4ed0                               jmp       (a0)     <--- jumps into wilderness

D