Re: [hatari-devel] Re: FPU emulation issue with Q2

On 26 April 2015 at 17:19, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:

Hi Doug,

Just for info, you should keep a version of the older winuae Core (the one where I tried to be as close as possible to the 68030 cycles).
The newer core is less accurate with cycles (in cycle exact mode, I think all instructions are taking 2 cycles).

Nicolas is working on the cycle exact (68000 mode for now if I understand well what he does).

So, for now, the new core in cycle exact mode is experimental, but it also fixes many bugs by comparing with the previous winuae core.

Maybe one day we'll have a full atari all computers perfect emulation ;)

Regards

Laurent

Le 26/04/2015 15:28, Douglas Little a écrit :

Sorry I just noticed the subject was not accurately reflecting the current problem. I think it began as a problem in 040/060 mode when I first got the new Hatari some months back, but later discovered it affects 030+882 mode as well.

So to de-confuse the situation I'll restate it.

I'm currently having trouble running a 68030+FPU binary in 68030+FPU Falcon emulation mode under WinUAE in cycle-accurate mode @ 16MHz.

If I disable both prefetch mode and cycle-accurate mode it stops crashing. If I enable either of those, it crashes executing FPU stuff with a variety of weird causes.

Unfortunately trying to use Hatari in non-cycle-accurate mode causes the program to run way too fast (about 1.6x the speed!) and creates other problems.

Before the UAE core upgrade, I was able to use cycle-accurate mode.

No 040/060 code or CPU emulation is actually involved - yet - although the intent is to get that working also once this problem has been identified.

Hope that is a lot clearer now. :)

Doug.

On 26 April 2015 at 10:30, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

I should add that I'm compiling the code with the following, intended for a normal Falcon + 882.

m68k-atari-mint-gcc -c -m68030 -m68881 -O2 -fomit-frame-pointer -D__ATARI__ -D__BIG_ENDIAN__ -DSUPER -I3rdparty/ -x c -
std=c99 -Wall -Wno-comment -Wno-unused-variable ............

On 26 April 2015 at 10:16, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

I started looking at this again today and performed a new test with the latest Win Hatari (SDL1/WinUAE build from antarctica.no).

My program still crashes in the same approx location. This is during the loading and setup of bulk integer & float data from a file format. There is no hardware-level stuff going on at this stage of the program. Just memory allocation and calculation.

The original file loader was implemented in C in a haphazard way over time and was quite messy so I recently reimplemented it from scratch in C++. This has had no impact on the crash, which suggests memory allocation is not involved since the allocation model, ownership and order of things has completely changed.

The calculations being performed however remain the same...

New information:

1) The first function in which the crash occurs is calculating polygon extents in texture space from texture UVs. This involves many calls to the standard floor()/ceil() functions but the rest is calculation internal to the function. I removed these calls and implemented them by hand - and the program continues past the crashing point, soon crashing elsewhere.

I should add that the breakpoint I set 'b pc=($8)' does not trigger for this crash, despite Hatari reporting a bus error. The debugger is configured to do so, but it doesn't seem to be happening reliably.

2) The point at which the second crash occurs is also interesting. It is interesting partly (again) because the debugger does not halt on the first breakpoint. There are several breakpoints happening in sequence and the program breaks after *many* of them have occurred.

Unknown FPU instruction F201 0003B656
2. CPU breakpoint condition(s) matched 19 times.
        pc = ( $8 )
3. CPU breakpoint condition(s) matched 3 times.
        pc = ( $c )
4. CPU breakpoint condition(s) matched 10 times.
        pc = ( $10 )

CPU=$e00fb6, VBL=4228, FrameCycles=3558, HBL=6, LineCycles=486, DSP=$583
$00e00fb6 : 48f8 ffff 0384                     movem.l   d0-d7/a0-a7,$0384.w
>

Last of all, the second crash relates to an emulator complaint about an unsupported FPU operation. As usual, the disassembler has trouble disassembling most FPU instructions so I'll need to decode this by hand to find out what it is. BTW this is true of both disassemblers, although the gaps in each are different.

$00e00fb6 : 48f8 ffff 0384                     movem.l   d0-d7/a0-a7,$038
> d $3b656
$0003b656 : f29d                               DC.W      $f29d
$0003b658 : ffca                               DC.W      $ffca
$0003b65a : f200 1528                          fsub.x    fp5,fp2
$0003b65e : f201                               DC.W      $f201
$0003b660 : 6500 f201                          bcs       $3a863
$0003b664 : 4500                               chk.l     d0,d2
$0003b666 : 2081                               move.l    d1,(a0)
$0003b668 : f23c 4538 3fe0 0000                fcmp.s    #$3fe00000,fp2

So while I'm still not exactly sure what's going on, I'm becoming more sure that there is something wrong with the new Hatari's floating point emulation (aside from the disasm gaps - the emulator is broken somehow). Perhaps specific to 881/882 operations which are no longer common in software built for 68060 devices? Or maybe some functionality that the float library calls depend on - e.g. float exceptions - and which the compiled code does not.

(Once again: real HW does not show this issue. Versions of Hatari prior to the 'new core' upgrade do not show this issue either..).

I'm short of time today but will try to look deeper next week.

(Eero - I'll try to get you a test build sometime next week which shows these issues, at least for the debugger breakpoint problem which seems to be a separate thing).

Doug.

On 4 March 2015 at 14:48, Douglas Little <doug694@xxxxxxxxxxxxxxx> wrote:

OK, so back to the opcode ff70, and looking at 68030 user manual chapter 10.1.3 with the format of line F instructions, it is stated that CpID 001 (bit 9 to 11) is used for 68881 and 6882, and 111 is reserved.

So, this really looks like an illegal instruction that should not be used in the 1st place. Is this handmade asm, or the result of a C compiler ?

This case was the result of the C compiler. However, I also noted that the PC addresses were incrementing by strange values in the debugger trace - too big for normal instructions ($00028092 -> $000280ce). So it may well have just run off into dead space by that point. The whole thing looks quite strange TBH.

I'll try to get something a bit more concrete later on after work.

D