On 10.02.2025 15:39, LIU Hao wrote:
在 2025-02-10 22:14, Jacek Caban 写道:
The MinGW variant of ARM64EC is still undefined, meaning we have the
flexibility to decide how it should work. There is an argument that
ARM64EC should support 80-bit long double, as full interoperability
is a core principle of ARM64EC, and lacking it goes against that.
What you're seeing with x87 FPU emulation is a function of the
emulator itself. See also [1] for some interesting challenges that
FEX had to address. In MSVC ARM64EC, this isn't directly exposed to
ARM64EC code, at least from the compiler's perspective. Register
mapping is well-defined [2], meaning it would theoretically be
possible to access x87 FPU values in ARM64EC assembly by combining
registers (e.g., R1 could be derived from x6 and a subset of x16).
On x86-32 (a.k.a. i686-w64-mingw32), the x87 FPU is used to return
floating-point values from functions. And more importantly, it is the
only hardware way to perform conversion between `long long` and
`double`, and to load or store a `long long` [1].
This requires x87 to have been set up in 64-bit extended precision.
However Windows initializes x87 to 63-bit double precision, so with
MSVC such operations are subject to precision loss, and therefore have
to be implemented in software.
We cannot give up x87 unless we make GCC and Clang stop generating
such code.
I didn’t mean to suggest changing any of that, x87 is part of the 32-bit
x86 ABI, and we can't change that. What I meant is making long double a
64-bit built-in C type, i.e. sizeof(long double) == 8. The compiler
could generate the same code for long double as it currently does for
double (aside from differences in built-in function names).
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
