Re: [hatari-devel] FPU status register handling & fmovem.x bugs

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Are you using SoftFloat or native float emulation for this test? I think the errors in lines 34 to 49 might be caused by native floats being only 64 bit wide. I highly recommend using SoftFloat generally.

For FPSR and FPCR: The value in FPCR seems to match the documentation. From FPSR I would have expected 0x0FFFFFF8 according to the documentation. Unfortunately I have no real hardware to test.
I think I read somewhere, that illegal combinations of exception status flags are accepted. But I might be wrong.


Am 01.06.2018 um 03:22 schrieb Thorsten Otto <admin@xxxxxxxxxxx>:

Hi,

 

while running some tests, i get some errors when running them on Hatari. The source & binaries are attached. From the fmovem.x in lines 34-49 i get following errors:

 

fmovem.c:45: test 1(0): expected 40000000:c90fdaa2:2168c235 got 40000000:c90fdaa2:2168c000
fmovem.c:46: test 1(0): expected 3ffe0000:b17217f7:d1cf79ac got 3ffe0000:b17217f7:d1cf7800
fmovem.c:47: test 1(0): expected 40000000:c90fdaa2:2168c235 got 40000000:c90fdaa2:2168c000
fmovem.c:48: test 1(0): expected 3ffe0000:b17217f7:d1cf79ac got 3ffe0000:b17217f7:d1cf7800
Looks like some bits are truncated during the move.

 

The write/read of fpcr on line 61 gives:

 

fmovem.c:61: test 2(0): expected 0x0000fff0, got 0x0000ffff
According to the manual, bits 0-3 should be read as zero.

 

And the write/read of the fpsr yields:

 

fmovem.c:74: test 3(0): expected 0x0fffffff, got 0xffffffff

Similar here, bits 28-31 should be read as zero. An interesting question though whether the expectation of the status flags i correct. The code does

 

                       moveq #-1,d0
                       fmove.l d0,fpsr
                       fmove.l fpsr,return_value
that is, it sets all flags for neg/nan/zero/inf. Of course, such a status could never result from some FP operation, since a result cannot be a nan and inf at the same time. Can someone verify what this test yields on real hw?

 

 

<fmovem.c><fmovem.ttp><testdriver.h>



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/