On 10.02.2025 02:22, LIU Hao wrote:
在 2025-02-09 22:48, Jacek Caban 写道:
From: Billy Laws <blaw...@gmail.com>
Signed-off-by: Jacek Caban <ja...@codeweavers.com>
---
mingw-w64-headers/crt/fenv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
While there doesn't seem to be any issue in this series of patches, I
would like to ask whether `long double` should be 64-bit or 80-bit on
ARM64EC.
In a sense, ARM64EC provides binary interoperability with x64
emulation, which seems to me that `long double` should be 80-bit.
My experiments on Huawei MateBook E Go suggest that, for x64 emulation
the x87 FPU is emulated with standard `double`, and except it takes
more space it provides no additional precision.
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).
However, implementing this would place a significant burden on the
compiler. There are two theoretical approaches:
- Full software emulation, where every operation relies on a library
call. This would be terrible for performance.
- Treating long double as 64-bit in code and performing conversions
(upcasting/downcasting) on load, store, and in ARM64EC entry/exit thunks.
The second approach seems preferable but still introduces non-trivial
complexity to the compiler. Beyond that, we wouldn’t be able to directly
use long double functions from msvcrt/ucrt, as we currently do for ARM64
in mingw-w64-crt, adding even more burden on the CRT side.
Stepping back from ARM64EC, I dislike how MinGW handles long double on
x86. While it’s often called a MinGW "feature", I see it more as a
historical mistake that we now maintain for compatibility. I wasn’t
around when it was introduced, but I suspect early GCC MinGW ports
simply mirrored Linux behavior for convenience. The result is a major
incompatibility with the Windows ecosystem, forcing us to maintain extra
long double functionality in mingw-w64-crt.
For that reason, I’d prefer not to extend this hack/feature/bug to
ARM64EC. I think that a more productive approach would be enabling an
x86 MinGW toolchain that uses 64-bit long double. This would require
changes to both the compiler and mingw-w64, making it incompatible with
current toolchains. However, this wouldn’t be drastically different from
existing toolchains targeting different CRT DLLs. Such a toolchain would
be natively compatible with ARM64EC.
In other words, I’d argue that the real issue isn't ARM64EC lacking
80-bit long double support, it's x86_64 lacking 64-bits long doubles. I
know this may be a controversial point of view.
Thanks,
Jacek
[1] https://p.ocmatos.com/blog/fex-x87-stack-optimization.html
[2]
https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions#register-mapping-for-integer-registers
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
