Timeline for Did any compiler fully use Intel x87 80-bit floating point?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 6 at 17:56 | history | edited | André LFS Bacci | CC BY-SA 4.0 | added 1351 characters in body |
| Feb 5 at 17:18 | comment | added | Sneftel | I don't really see how this is specific to 80-bit precision. If you decide to call external code which changes the FP state without restoring it, then you could potentially run into problems regardless of which precision you had previously set it to. | |
| Feb 5 at 2:47 | comment | added | davidbak | Science and engineering yes. But if your finance code is using binary floating point instead of decimal fixed or floating point it's already broken even before it runs on machines with different floating point settings. | |
| Feb 4 at 21:54 | comment | added | Peter Cordes | Also related: Why am I able to perform floating point operations inside a Linux kernel module? | |
| Feb 4 at 21:53 | comment | added | Peter Cordes | FPU environment is a per-thread thing, no matter what FPU you're using on what ISA, like i386 with x87, x86-64 with SSE, AArch64 with ASIMD and its scalar FP instructions, ARM 32-bit with VFP or NEON, etc. Most of these have configurable rounding modes and some have exceptions that can be unmasked, hence standard C functions like fegetround (en.cppreference.com/w/cpp/numeric/fenv). And portable glibc functions like feenableexcept to unmask. (x87 is the only ISA I know of where precision is an FPU setting instead of different opcodes.) | |
| Feb 4 at 21:51 | comment | added | Peter Cordes | Anyway, sane non-buggy systems save/restore the full x87 state on context switch, historically using fsave / frstor, or more recently using xsaveopt / xrstor or similar. | |
| Feb 4 at 21:46 | comment | added | Peter Cordes | Having runtime-variable precision that a bad driver can also screw up is maybe a reason to stick to the usual default I guess, if such bad drivers are common. | |
| Feb 4 at 21:46 | comment | added | Peter Cordes | All you're saying is that buggy drivers are a problem. (Either kernel code munging the FPU state, or a DLL loaded into your process). You'd have the same problem with FP exceptions using SSE floating point if the buggy printer driver enabled exceptions in MXCSR instead of in the x87 control word (e.g. because it was newer and used SSE floating-point itself). Also, that's a problem whether you use x87 FP with 53-bit or 64-bit mantissa precision. | |
| Feb 4 at 20:32 | comment | added | Adam Hyland | Velvel Kahan has a talk about this exact issue "Why can I Debug some Numerical Programs that You Can’t ?". Printing itself is so tough that a canonical 1990 paper "How to Print Floating-Point Numbers Accurately" got a 2003 retrospective paper. | |
| Feb 4 at 19:12 | history | answered | André LFS Bacci | CC BY-SA 4.0 |