Re: [hatari-devel] FPU update

[Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>]

I don't know that emulation. To be useful it would need to emulate the 6888x FPU specifically. Some general FPU emulation would not help us.

Furthermore it needs to be somehow readable. If it is written in assembly i'll certainly have problems translating it to something useful. I already have some FPU emulation code written in assembler. But it is almost impossible for me to read and reproduce in C.

Am 23.01.2017 um 19:11 schrieb Mariusz Buras <mariusz.buras@xxxxxxxxx>:

Hi, just an idea.. Would the FPU emulation that was included in Linux kernel be of any use as a reference?

Regards

Mariusz

On 23 January 2017 at 17:47, Andreas Grabher <andreas.grabher@xxxxxxxxxxxx> wrote:

Am 21.01.2017 um 14:42 schrieb Douglas Little <doug694@xxxxxxxxxxxxxx>:

> Hi,
>
> I have quite a lot of float based 68k code (asm and C), some of which is quite sensitive to rounding and other fun things - varied implementations of floor() and integer conversion, some handwritten pow() operations etc. If/when this makes it into a version of Hatari I can compile I can do some tests with it.
>
> I also created a simple 6888x conformance/correctness test recently, which was probably posted here a while back. Might be interesting to run the softfloat impl. against that sometime.
>
> Doug.
>

Hello Douglas,

your FPU test utility is good for testing for faulty chips, but is not exactly what we need for debugging the emulator. For every failing calculation i'd need to know the input operands and the result as it is and as it should be.
Would it be hard to modify your test program to serve that purpose? Or would it create too much data?
Theoretically i'd only need to test through all kinds of operands once (normal in range, denormal, zero, infinity (all +/-), nan and snan) and for some functions produce some special conditions (underflow, overflow). For the dyadic operations we'd need to test all combinations (normal + normal, normal + denormal, normal + zero ... denormal + zero, denormal + infitiniy ...).

Well, the longer i think about it, the more test cases come to my mind. One would certainly have to think a while to not miss an important test case.
At the moment i'm a little bit clueless on how to debug this. Simply following the data sheet (did that for the 68030 MMU) seems to be not good enough.

Best wishes,

Andreas