<div dir="ltr">It does work on 64-bit Windows, it's just technically deprecated.<div><br></div><div>Beyond that, the 80-bit Extended type dates back to the mid 1980s, and ran on a particular part of the processor (the FPU, or Floating Point Unit), in such a way that it was able to provide a somewhat higher amount of precision than the 64-bit "Double" type that's most commonly used today. That said, the operations involved generally weren't / aren't nearly as efficient as the vector based SSE2+ ones used for 32-bit and 64-bit floats. So it fell out of favor for most use cases, outside of certain things like scientific code that actually needs the highest amount of precision possible even at the detriment of efficiency.</div><div><br></div><div>I'd personally argue that anyone writing code today that actually needs true 80-bit extended already certainly is likely to know what they're doing as far as tooling, thus meaning the majority of users are fairly unlikely to ever encounter any problems that directly relate to it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 12, 2022 at 11:08 PM Travis Siegel via fpc-devel <<a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 1/12/2022 5:20 PM, Sven Barth via
fpc-devel wrote:<br>
</div>
<blockquote type="cite">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>
</div>
_______________________________________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a><br>
<a href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" rel="noreferrer" target="_blank">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a><br>
</blockquote></div>