Am 01.06.2018 um 09:40 schrieb Thorsten Otto <admin@xxxxxxxxxxx>:
On Freitag, 1. Juni 2018 09:17:51 CEST Andreas Grabher wrote:> Are you using SoftFloat or native float emulation for this test?
TBH, not sure; i'm using a version i compiled myself, without setting any options.
>might be caused by native floats being only 64 bit wide.
But that's unnecessary. At least on linux and win32, all relevant functions also exist for long double. You might not get bitwise exact values, due to differences in rounding, but you could represent at least the whole range.
Wikipedia: "On the x86 architecture, most C compilers implement long double as the 80-bit extended precision type supported by x86 hardware (sometimes stored as 12 or 16 bytes to maintain data structure alignment), as specified in the C99 / C11 standards (IEC 60559 floating-point arithmetic (Annex F)). An exception is Microsoft Visual C++ for x86, which makes long double a synonym for double."
This was a misunderstanding. I meant the expected value matches documentation (in contrast to FPSR, where it doesn't; see below). Of course the value from the emulated FPU seems be wrong.
>The value in FPCR seems to match the documentation.
I don't think so:
<image.png>
Bits 3-0 should read as zero.
>From FPSR I would have expected 0x0FFFFFF8 according to the documentation.
Maybe. Bits 0-2 are left empty in the description, so they seem to be undefined.
In my documentation (MC68881/MC68882 Floating-Point Coprocessor User's Manual, First Edition) I have this:
