Hi Collin,
> I can look at porting it but I have no knowledge of x86 floating point,
Thanks for volunteering to handle this.
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.
> I was experimenting with Windows recently after the recent gperf thread.
> In a "MSYS2 MINGW64" window I found that a gnulib testdir of all modules
> fails to build due to the following assertion in fenv-env.c:
>
> verify (sizeof (fenv_t) >= sizeof (x86_387_fenv_t));
>
> Upon investigating, I found that MingGW-w64 had changes to fenv.h and
> it's functions ~2 months ago [1].
> [1]
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/5c5973cf5f021db8fd75e9667e63881ccd169320
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.
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.
Bruno
