[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?

Ben Grasset operator97 at gmail.com
Thu Jan 13 06:44:29 CET 2022


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

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20220113/65ad09dc/attachment.htm>


More information about the fpc-devel mailing list