<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/13/22 05:59, Travis Siegel via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:099d8e0d-ea03-23bf-9ae6-8497484c12d9@softcon.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 1/12/2022 5:20 PM, Sven Barth via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4078ce17-dc02-00e7-8039-702ca5c8a396@googlemail.com">When
compiling from a target supporting Extended to one only
supporting Double there isn't a loss of precision when
calculating values at compile time. The other way around
however, there *is* and that is the more crucial problem.<br>
<br>
Regards,<br>
Sven<br>
<br>
</blockquote>
<p><i>I understand only part of this issue. 64-bit windows
doesn't have extended support, is there a reason for this? If
it's simply processors, and it works on linux, why does it not
work on windows?</i></p>
<p><i>Also, since it's 64-bit, wouldn't a double on a 64-bit
system match or exceed the numeric range on an extended range
for a 32-bit system?</i></p>
<p><i>I'm no expert on compiler numeric ranges, and 32/64 ranges
aren't something I've studied a whole lot of, other than to
note that 64-bit processors can handle *much* larger numbers,
so I don't understand why this problem exists.</i></p>
<p><i>Is there a summary of why this is a problem anywhere I can
refer to so I can understand why this happens, and what (if
anything) can be done to solve it?</i></p>
<p><i>I've always been fascinated by compilers, though I've never
actually written anything except an assembler for dos several
years ago, I was never able to extend that to other languages,
because of lack of knowledge of how the cpu does things, but
this is still an interesting topic for me, and I honestly
can't figure out why there would be an issue at all.</i></p>
<p><i>I'm not doubting there is one, I'm just missing a piece or
two to understand it.</i></p>
<p><i>Any help would be appreciated.<br>
</i></p>
</blockquote>
<p>The i386 compiler uses the x87 FPU for floating point. The x87
supports the 32-bit single precision floating point type, the
64-bit double precision floating point type and the 80-bit
extended precision extended floating point type. So, the best
precision you get is 80-bit.</p>
<p>The x86_64 compiler uses SSE2 instructions for floating point.
However, the SSE2 instructions only support 32-bit and 64-bit
float types.<br>
</p>
<p>X86_64 processors still have the FPU, and it still functions in
64-bit mode, so the x86_64 compiler can still use the FPU for the
80-bit extended type. In fact, this is why the linux x86_64
compiler works without limitations. However, Windows doesn't
guarantee future compatibility if the FPU is used.</p>
<p><a class="moz-txt-link-freetext" href="https://docs.microsoft.com/en-us/windows/win32/dxtecharts/sixty-four-bit-programming-for-game-developers?redirectedfrom=MSDN#Porting_to_64bit">https://docs.microsoft.com/en-us/windows/win32/dxtecharts/sixty-four-bit-programming-for-game-developers?redirectedfrom=MSDN#Porting_to_64bit</a></p>
<p>Quote:</p>
<p>"The x87, MMX, and 3DNow! instruction sets are deprecated in
64-bit modes. The instructions sets are still present for backward
compatibility for 32-bit mode; however, to avoid compatibility
issues in the future, their use in current and future projects is
discouraged."<br>
</p>
<p>A logical question that follows is how can they break it in
future Windows versions, if it's supported by the CPU. The answer
is, since Windows is a multitasking operating system, they might
stop saving the FPU registers when switching between 64-bit tasks.
So, the only guarantee that x87 FPU code will continue to work in
future Windows versions is if it's in a 32-bit process.</p>
<p>It kinda sucks, but it is what it is. Microsoft have decided that
the FPU is considered "legacy" and "deprecated". However, the
replacement (SSE2) doesn't have all the capabilities that the FPU
has, namely it doesn't have 80-bit extended precision. I guess,
you can complain to Microsoft about that and not to Free Pascal
developers, but I doubt that they will care. :)<br>
</p>
<p><br>
</p>
<p>Nikolay<br>
</p>
</body>
</html>