[fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Nikolay Nikolov]

On 9/28/20 12:30 AM, Tomas Hajny via fpc-devel wrote:
> On 2020-09-27 18:27, Nikolay Nikolov via fpc-devel wrote:
>> On 9/27/20 7:21 PM, Florian Klämpfl via fpc-devel wrote:
>>> Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel:
>>>> On 27/09/2020 09:34, Sven Barth via fpc-devel wrote:
>>>>> Ben Grasset via fpc-devel <fpc-devel at lists.freepascal.org 
>>>>> <mailto:fpc-devel at lists.freepascal.org>> schrieb am So., 27. Sep. 
>>>>> 2020, 07:50:
>>>>>
>>>>>     That last quote is absolute BS, to be very frank. There is no
>>>>>     reason whatsoever not to use a natively-64-bit copy of FPC if
>>>>>     running a natively-64-bit copy of Windows, and there hasn't been
>>>>>     for well over half a decade at this point.
>>>>>
>>>>>
>>>>> Yes, there is a reason: you can not build a i8086 or i386 cross 
>>>>> compiler with the Win64 compiler (or any non-x86 compiler to be 
>>>>> fair) due to missing Extended support. Thus the majority of the 
>>>>> FPC Core team considers the Win64 compiler as inferior and also 
>>>>> unnecessary cause the 32-bit one works just as well on that platform.
>>>>>
>>>> Just my 2 cents.
>>>>
>>>> Well, one the one hand, native 64 bit is only really important if 
>>>> it can do something that 32 bit can not do. (faster, bigger 
>>>> sources, ....).
>>>>
>>>> On the other hand, not everyone needs a win64 to win32 cross 
>>>> compiler. And if they do, a native 32bit compiler can be renamed 
>>>> and will happily serve as such a cross compiler. (But that is not a 
>>>> must be included / such workarounds may not be wanted, especially 
>>>> since they might cause repeated extra work)
>>>>
>>>> So the question here is/are imho about the work it takes to amend 
>>>> the release-build process (i.e. update the scripts). And then the 
>>>> amount of extra time needed for each release (build and testing).
>>>
>>> The thing is: we would distribute a compiler (the x86_64-win64 one) 
>>> which claims to be able to compile to e.g. to x86_64-linux, but it 
>>> would generate programs which might behave differently than natively 
>>> compiled ones as float constants are handled internally different.
>>
>> And in this particular case, "different" means "less accurate", due to
>> rounding errors, caused by compile time conversion of 80-bit extended
>> float constants to 64-bit double precision constants. And "less
>> accurate" is bad. :)
>
> Sorry for a silly question, but is it really the case that a higher 
> precision is good (or that it doesn't matter at least)? I assume that 
> performing compile-time calculations in higher precision than 
> calculations performed at run-time may still result in differences 
> and, in spite of the fact that the calculations are more precise, the 
> differences may still lead to confusion of our users (if not something 
> worse) - especially if it may not be always clear which part will be 
> computed at compile-time and which part at run-time. Is my 
> understanding correct? Or is there some solution allowing to achieve 
> specific precision with a higher precision library?

I don't have an exact answer, but I think higher precision is better, 
compared to lower. You can not expect bitwise identical result, when 
using floating point calculations anyway. For example AMD and Intel FPUs 
perform calculations with some very slight variations, so the same 
calculation doesn't always result in the same bitwise identical floating 
point number, even though, they're practically really close, so it 
doesn't matter. I don't know of any program that breaks e.g. on AMD 
FPUs, because it was designed for Intel or vice versa.

In theory this matters, if we implement 128-bit soft float support in 
the compiler, or if we encounter an FPU that supports 128-bit floating 
point. The question is whether it's safe to implement 80-bit x87 FPU 
floating point support on host targets with 128-bit FPU support. I think 
it's safe, but I'm not an expert on floating point.

But compile time calculations having a lower precision, compared to the 
runtime precision is definitely bad.

Nikolay