[fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC website for the next release?

[Nikolay Nikolov]

On 1/13/22 07:44, Ben Grasset via fpc-devel wrote:
> It does work on 64-bit Windows, it's just technically deprecated.
>
> Beyond that, the 80-bit Extended type dates back to the mid 1980s,
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.
> and ran on a particular part of the processor (the FPU, or Floating 
> Point Unit),

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.

The Pentium was the first CPU that always had the FPU integrated.

> 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.

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.).

>
> 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.
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.
>
> On Wed, Jan 12, 2022 at 11:08 PM Travis Siegel via fpc-devel 
> <fpc-devel at lists.freepascal.org> wrote:
>
>
>     On 1/12/2022 5:20 PM, Sven Barth via fpc-devel wrote:
>>     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.
>>
>>     Regards,
>>     Sven
>>
>     /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?/
>
>     /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'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./
>
>     /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'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'm not doubting there is one, I'm just missing a piece or two to
>     understand it./
>
>     /Any help would be appreciated.
>     /
>
>     _______________________________________________
>     fpc-devel maillist  - fpc-devel at lists.freepascal.org
>     https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>
> _______________________________________________
> fpc-devel maillist  -fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20220113/ae24d4e5/attachment-0001.htm>