Bruno Haible <br...@clisp.org> writes: > When working on the floating-point code, one needs to have the hardware > specification handy. In this case, it is the > Intel® 64 and IA-32 Architectures Software Developer’s Manual > Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4 > (4700 pages) > > Then, what one needs to understand, is that the x86 and x86_64 CPUs > have two floating-point units: > - The old i386/387 unit, with instructions that work on a small > "floating-point register stack", > - The newer MMX / SSE unit, with instructions that explicitly specify > the register. > And accordingly, it has two different status+mask registers. > > On MSVC, the old i386/387 unit is not used (the compiler just does not > emit such instructions), therefore for MSVC the fenv code is approximately > as simple as for other CPUs.
Thanks for the reference and pointers. I have the document from when I was messing with the cpuid instruction a while ago. > I was going to say: That will not be hard to port. You just need to > make a configure test for the expression > sizeof (fenv_t) <= 8 > and treat that case of > (defined __i386__ || defined __x86_64__) && defined _WIN32 && !defined > __CYGWIN__ > like _MSC_VER. Yes, looking at the MinGW patch I thought the same. So I used some sed expressions to force the _MSC_VER code path to be used. But the Gnulib 'fenv-*' tests failed. > But that mingw change is likely to not work at all. Because gcc can > emit instructions that use the old i386/387 unit: > (a) When the program uses 'long double' values, > (b) When the option -mfpmath=387 is used, cf. > https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html > > So, the first thing is to try out some uses of <fenv.h> with (a) or (b), > and see whether that works. I'll have a look. Thanks! Collin
