Laurent Vivier <laur...@vivier.eu> writes:
> Le 29/04/2020 à 11:26, Alex Bennée a écrit : >> >> Laurent Vivier <laur...@vivier.eu> writes: >> >>> Le 28/04/2020 à 20:43, Alex Bennée a écrit : >>>> >>>> KONRAD Frederic <frederic.kon...@adacore.com> writes: >>>> >>>>> The MC68881 say about infinities (3.2.4): >>>>> >>>>> "*For the extended precision format, the most significant bit of the >>>>> mantissa (the integer bit) is a don't care." >>>>> >>>>> https://www.nxp.com/docs/en/reference-manual/MC68881UM.pdf >>>>> >>>>> The m68k extended format is implemented with the floatx80 and >>>>> floatx80_invalid_encoding currently treats 0x7fff00000000000000000000 as >>>>> an invalid encoding. This patch fixes floatx80_invalid_encoding so it >>>>> accepts that the most significant bit of the mantissa can be 0. >>>>> >>>>> This bug can be revealed with the following code which pushes extended >>>>> infinity on the stack as a double and then reloads it as a double. It >>>>> should normally be converted and read back as infinity and is currently >>>>> read back as nan: >>>> >>>> Do you have any real HW on which you could record some .ref files for >>>> the various multiarch float tests we have (float_convs/float_madds)? >>>> Does this different of invalid encoding show up when you add them? >>> >>> On my side, in the past when I started to implement m68k FPU, I used >>> TestFloat and SoftFloat I have ported to m68k and I compare the result >>> in QEMU and in a Quadra 800. >> >> Surely TestFloat and SoftFloat is all emulation though? >> >> Anyway if you have a Quadra 800 running Linux could you generate some >> .ref files for the float_convs and float_madds test cases. The binaries >> are static so you should just be able to copy them and run. >> >> > > Here are the files I have generated on Q800. So running those with: run-float_convs: QEMU_OPTS += -cpu m68040 run-float_madds: QEMU_OPTS += -cpu m68040 We see the m68k float needs a fair bit of work from the get go: Reference qemu-m68k -cou m68040 ### Rounding to nearest ### Rounding to nearest > from single: f32(-nan:0xffbfffff) > to double: f64(-nan:0x00fff7ffffe0000000) (OK) > to int32: 2147483647 (OK) > to int64: 9223372034707292159 (OK) > to uint32: 2147483647 (OK) > to uint64: 9223372034707292159 (OK) from single: f32(-nan:0xffffffff) from single: f32(-nan:0xffffffff) to double: f64(-nan:0x00ffffffffe0000000) (OK) to double: f64(-nan:0x00ffffffffe0000000) (OK) to int32: 2147483392 (INVALID) | to int32: 2147483647 (OK) to int64: 9223370939490631424 (INVALID) | to int64: 9223372034707292159 (OK) to uint32: 2147483392 (INVALID) | to uint32: 2147483647 (OK) to uint64: 9223370939490631424 (INVALID) | to uint64: 9223372034707292159 (OK) from single: f32(-nan:0xffffffff) | from single: f32(nan:0x7fffffff) to double: f64(-nan:0x00ffffffffe0000000) (OK) | to double: f64(nan:0x007fffffffe0000000) (OK) to int32: 2147483392 (INVALID) | to int32: 2147483647 (OK) to int64: 9223370939490631424 (INVALID) | to int64: 9223372034707292159 (OK) to uint32: 2147483392 (INVALID) | to uint32: 2147483647 (OK) to uint64: 9223370939490631424 (INVALID) | to uint64: 9223372034707292159 (OK) from single: f32(-inf:0xff800000) < to double: f64(-inf:0x00fff0000000000000) (OK) < to int32: -2147483648 (INVALID) < to int64: 1 (INVALID) < to uint32: -2147483648 (INVALID) < to uint64: -9223372034707292160 (INVALID) < from single: f32(-0x1.fffffe00000000000000p+127:0xff7fffff) from single: f32(-0x1.fffffe00000000000000p+127:0xff7fffff) to double: f64(-0x1.fffffe00000000000000p+127:0x00c7efffffe to double: f64(-0x1.fffffe00000000000000p+127:0x00c7efffffe to int32: -2147483648 (INVALID) | to int32: -2147483648 (OK) to int64: 1 (INVALID) | to int64: 1 (OK) to uint32: -2147483648 (INVALID) | to uint32: -2147483648 (OK) to uint64: -9223372034707292160 (INVALID) | to uint64: -9223372034707292160 (OK) snipped a bunch more. -- Alex Bennée