<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 07:44, Ben Grasset via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL4d7FgDAvdDgGetgOvKajVDGr02rXKTZguFDMG3gD6iE3R2dw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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,</div>
</div>
</blockquote>
The year 1980, not the mid 1980s. But the x86 family dates back to
1978. Most x86_64 instructions are the same as the ones, introduced
in 1978, but with an added prefix to indicate they're 64-bit.<br>
<blockquote type="cite"
cite="mid:CAL4d7FgDAvdDgGetgOvKajVDGr02rXKTZguFDMG3gD6iE3R2dw@mail.gmail.com">
<div dir="ltr">
<div> and ran on a particular part of the processor (the FPU, or
Floating Point Unit),</div>
</div>
</blockquote>
<p>Ran on an optional separate coprocessor chip, called Intel 8087.
It was succeeded by 80187, 80287, 80387 and 80487. It was actually
integrated into the CPU with the 486DX CPU, but the 486SX had no
FPU (in fact, it was disabled). And the 487 was actually a 486DX
in a different socket, that took full control of the system as
soon as it was installed, while the 486SX on the motherboard was
switched off.</p>
<p>The Pentium was the first CPU that always had the FPU integrated.<br>
</p>
<blockquote type="cite"
cite="mid:CAL4d7FgDAvdDgGetgOvKajVDGr02rXKTZguFDMG3gD6iE3R2dw@mail.gmail.com">
<div dir="ltr">
<div> 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>
</blockquote>
<p>We do care about scientific code as well as fast code, that's why
we support both the FPU and SSE2+ (as well as AVX, etc.).<br>
</p>
<blockquote type="cite"
cite="mid:CAL4d7FgDAvdDgGetgOvKajVDGr02rXKTZguFDMG3gD6iE3R2dw@mail.gmail.com">
<div dir="ltr">
<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>
</blockquote>
Floating point precision bugs, caused by loss of precision are evil,
because the code works most of the time during testing, but they can
still cause intermittent faults, which can be catastrophic. Ariane 5
is a notable example.<br>
<blockquote type="cite"
cite="mid:CAL4d7FgDAvdDgGetgOvKajVDGr02rXKTZguFDMG3gD6iE3R2dw@mail.gmail.com"><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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">fpc-devel@lists.freepascal.org</a><br>
<a
href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a><br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
fpc-devel maillist - <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
</blockquote>
</body>
</html>