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

2020-09-27 Thread Florian Klämpfl via fpc-devel 


> Am 28.09.2020 um 00:32 schrieb Nikolay Nikolov via fpc-devel 
> :
> 
> 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.

This is way we should implement it completely in software: we get the same 
results on all platforms though they may deviate slightly from runtime results.

> 
> But compile time calculations having a lower precision, compared to the 
> runtime precision is definitely bad.
> 
> Nikolay
> 
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Nikolay Nikolov via fpc-devel 


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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Marco van de Voort via fpc-devel 


Op 2020-09-27 om 18:21 schreef Florian Klämpfl via fpc-devel:




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.


Or just block forbidden combinations wrt crossbuilding in the build 
system, rather than the release versions.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Tomas Hajny via fpc-devel 

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


Tomas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Florian Klämpfl via fpc-devel 

Am 27.09.20 um 22:12 schrieb denisgolovan:

Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel:

Not for 80 bit extended, but it would be the clean solution with
float128 support being optional in some architectures (RiscV, Sparc64,
PPC64). So if we change it, we should do it right as 80 Bit has the same
problem: missing transcendent functions in software.


Of course, what we could do for the compiler (not the rtl!): to
translate libquadmath. It is LPGL so perfectly usable with in the compiler.


I see now.
However libquadmath is quite slow to be really useful.
Double float is around 20x slower than native double, float128 would be around 
100x slower.


This doesn't matter. It is needed "only" for constant expression 
evaluation inside the compiler. Speed is negligible in this case.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread denisgolovan via fpc-devel 
> Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel:
>> Not for 80 bit extended, but it would be the clean solution with
>> float128 support being optional in some architectures (RiscV, Sparc64,
>> PPC64). So if we change it, we should do it right as 80 Bit has the same
>> problem: missing transcendent functions in software.
> 
> Of course, what we could do for the compiler (not the rtl!): to
> translate libquadmath. It is LPGL so perfectly usable with in the compiler.

I see now.
However libquadmath is quite slow to be really useful.
Double float is around 20x slower than native double, float128 would be around 
100x slower.

-- Regards,
Denis Golovan
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Florian Klämpfl via fpc-devel 

Am 27.09.20 um 22:03 schrieb Florian Klämpfl via fpc-devel:

Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel:

Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel:

See above. It perfectly shows why it is frightening (not the basic
stuff, but the transcendent functions):
- there are little libraries being really IEEE compliant for float128
- if they are IEEE compliant, their license does not allow to use the
code in the FPC rtl.


Ok, the license is the problem.
However I still fail to see why full 128bit support is necessary for 
80bit Extended.




Not for 80 bit extended, but it would be the clean solution with 
float128 support being optional in some architectures (RiscV, Sparc64, 
PPC64). So if we change it, we should do it right as 80 Bit has the 
same problem: missing transcendent functions in software.


Of course, what we could do for the compiler (not the rtl!): to 
translate libquadmath. It is LPGL so perfectly usable with in the compiler.


What's strange though:

https://github.com/gcc-mirror/gcc/blob/master/libquadmath/math/cosq.c

It contains a sun copyright and not LGPL header ...

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Florian Klämpfl via fpc-devel 

Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel:

Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel:

See above. It perfectly shows why it is frightening (not the basic
stuff, but the transcendent functions):
- there are little libraries being really IEEE compliant for float128
- if they are IEEE compliant, their license does not allow to use the
code in the FPC rtl.


Ok, the license is the problem.
However I still fail to see why full 128bit support is necessary for 
80bit Extended.




Not for 80 bit extended, but it would be the clean solution with 
float128 support being optional in some architectures (RiscV, Sparc64, 
PPC64). So if we change it, we should do it right as 80 Bit has the same 
problem: missing transcendent functions in software.


Of course, what we could do for the compiler (not the rtl!): to 
translate libquadmath. It is LPGL so perfectly usable with in the compiler.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Florian Klämpfl via fpc-devel 

Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel:

See above. It perfectly shows why it is frightening (not the basic
stuff, but the transcendent functions):
- there are little libraries being really IEEE compliant for float128
- if they are IEEE compliant, their license does not allow to use the
code in the FPC rtl.


Ok, the license is the problem.
However I still fail to see why full 128bit support is necessary for 80bit 
Extended.



Not for 80 bit extended, but it would be the clean solution with 
float128 support being optional in some architectures (RiscV, Sparc64, 
PPC64). So if we change it, we should do it right as 80 Bit has the same 
problem: missing transcendent functions in software.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread denisgolovan via fpc-devel 
> See above. It perfectly shows why it is frightening (not the basic
> stuff, but the transcendent functions):
> - there are little libraries being really IEEE compliant for float128
> - if they are IEEE compliant, their license does not allow to use the
> code in the FPC rtl.

Ok, the license is the problem.
However I still fail to see why full 128bit support is necessary for 80bit 
Extended.

-- Regards,
Denis Golovan
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Florian Klämpfl via fpc-devel 

Am 27.09.20 um 20:57 schrieb denisgolovan via fpc-devel:

Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel:
So we would need softfloat extended support. This is doable with one
major obstacle: the "irrational" functions like ld, sin etc.: they need
precise enough implementations for 80 bit (actually, just adding and
using in the compiler 128 bit softfloat support would be even better).
And this is probably something which is really hard. While I believe ;)
I can solve most coding challenges, this is something I fear to touch :)


Well. Intel arch supports FMA instruction sets since 2013 (Intel) and since 
2012 (AMD).
See https://en.wikipedia.org/wiki/FMA_instruction_set


FPC supports for years (since 2014?) FMA intrinsic on CPUs having them.



Based on FMA support it's quite easy to create 128 bits (almost) semi-soft 
floats.


This is a half-backen solution imo. For the compiler IEEE compliant 128 
bit floats are a must.



Julia guys have a nice library called DoubleFloats 
(https://github.com/JuliaMath/DoubleFloats.jl, MIT licensed)


We cannot use MIT licensed code in the rtl.


They have a lot of trigonometric and other "complex" stuff already implemented.

So, maybe it's not that frightening after all :)


See above. It perfectly shows why it is frightening (not the basic 
stuff, but the transcendent functions):

- there are little libraries being really IEEE compliant for float128
- if they are IEEE compliant, their license does not allow to use the 
code in the FPC rtl.



See my own small port attached. Russian comments ahead so beware :)

-- Regards,
Denis Golovan


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread denisgolovan via fpc-devel 
> Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel:
> So we would need softfloat extended support. This is doable with one
> major obstacle: the "irrational" functions like ld, sin etc.: they need
> precise enough implementations for 80 bit (actually, just adding and
> using in the compiler 128 bit softfloat support would be even better).
> And this is probably something which is really hard. While I believe ;)
> I can solve most coding challenges, this is something I fear to touch :)

Well. Intel arch supports FMA instruction sets since 2013 (Intel) and since 
2012 (AMD).
See https://en.wikipedia.org/wiki/FMA_instruction_set

Based on FMA support it's quite easy to create 128 bits (almost) semi-soft 
floats.
Julia guys have a nice library called DoubleFloats 
(https://github.com/JuliaMath/DoubleFloats.jl, MIT licensed)
They have a lot of trigonometric and other "complex" stuff already implemented.

So, maybe it's not that frightening after all :)
See my own small port attached. Russian comments ahead so beware :)

-- Regards,
Denis Golovanunit uDF64;

{
   модуль для работы с Double F64 числами
   https://github.com/JuliaMath/DoubleFloats.jl
}

{$mode objfpc}{$H+}
{$ASMMODE INTEL}
{$modeswitch advancedrecords}
{$FPUType SSE42} //почему-то быстрее AVX/AVX2
{$Optimization DFA}

interface

uses
  Classes, SysUtils;

type
  TDF64 = record
hi,lo: Double;
  end;
  PDF64 = ^TDF64;
  PTDF64 = ^TDF64; //упрощение для макросов

operator -(const X : TDF64):TDF64;inline;
operator +(const A,B : TDF64):TDF64;
operator -(const A,B : TDF64):TDF64;
operator *(const A,B : TDF64):TDF64;
operator /(const X,Y : TDF64):TDF64;inline;

operator :=(const A:Double):TDF64;inline;
operator :=(const A:TDF64):Double;inline;
operator :=(const A:TDF64):NativeInt;inline;

operator=(const X, Y: TDF64): boolean;inline;
operator<(const X, Y: TDF64): boolean;inline;
operator<=(const X, Y: TDF64): boolean;inline;
operator>(const X, Y: TDF64): boolean;inline;
operator>=(const X, Y: TDF64): boolean;inline;

function Neg(const x:TDF64):TDF64;overload;inline;
function Inv(const x:TDF64):TDF64;overload;inline;
function Abs(const x:TDF64):TDF64;overload;inline;
function Max(const x,y:TDF64):TDF64;overload;inline;
function Min(const x,y:TDF64):TDF64;overload;inline;
function FMA(a,b,c:Double):Double;

function ToDF64(const a:Double):TDF64;inline;overload;
function ToDF64(const a:Int64):TDF64;inline;overload;
function ToF64(const a:TDF64):Double;inline;overload;
function ToStr(const p:TDF64):String;overload;

const ZeroDF64:TDF64 = (hi:0.0; lo:0.0);
const OneDF64:TDF64 = (hi:1.0; lo:0.0);

implementation
uses math, bigdecimalmath;

{$warn 2005 off} // disable "Comment level 2 found" warnings.
// $fpc -B -vwhilq -Fu./bigdecimalmath/ project1.lpr
// ... to see numbers for warnings

{
function FMA(a,b,c:Double):Double;
begin
  // SetRoundMode(rmNearest); - нужно округление до ближайшего
  asm
movlpdxmm0, [A]
movlpdxmm1, [B]
movlpdxmm2, [C]
vfmadd213sd xmm0, xmm1, xmm2 //a = a*b + c
//movhlps xmm1, xmm0
//vzeroupper
  end;
end;
}
function FMA(a,b,c:Double):Double;assembler;nostackframe;
asm
  // SetRoundMode(rmNearest); - нужно округление до ближайшего
  vfmadd213sd xmm0, xmm1, xmm2 //a = a*b + c
end;

function quick_two_sum(const a,b:Double): TDF64;inline;
begin
  Result.hi:=a+b;
  Result.lo:=b-(Result.hi-a);
end;

{
function TwoSum(a::T, b::T) where {T<:AbstractFloat}
s  = a + b
a1 = s - b
b1 = s - a1
da = a - a1
db = b - b1
t  = da + db
return s, t
end
}

function two_sum(const a, b:Double):TDF64;inline;
var hi, lo, a1, b1: Double;
begin
  hi := a + b;
  a1 := hi - b;
  b1 := hi - a1;
  lo := (a - a1) + (b - b1);
  Result.hi := hi;
  Result.lo := lo;
end;

(*
@inline function two_hilo_sum(a::T, b::T) where {T<:FloatWithFMA}
s = a + b
e = b - (s - a)
return s, e
end
*)
function two_hilo_sum(const a, b:Double):TDF64;inline;
begin
  Result.hi:=a+b;
  Result.lo:=b - (Result.hi - a)
end;

function two_prod(const a,b:Double): TDF64;inline;
begin
  Result.hi:=a*b;
  Result.lo:=FMA(a,b,-Result.hi);
end;

(*
@inline function two_diff(a::T, b::T) where {T<:FloatWithFMA}
hi = a - b
a1 = hi + b
b1 = hi - a1
lo = (a - a1) - (b + b1)
return hi, lo
end
*)
function two_diff(const a,b:Double): TDF64;inline;
var a1,b1:Double;
begin
  Result.hi:=a - b;
  a1:=Result.hi + b;
  b1:=Result.hi - a1;
  Result.lo:=(a - a1) - (b + b1);
end;

(*
 @inline function add__dd(x::Tuple{T,T}, y::Tuple{T,T}) where T<:IEEEFloat
xhi, xlo = x
yhi, ylo = y
hi, lo = two_sum(xhi, yhi)
thi, tlo = two_sum(xlo, ylo)
c = lo + thi
hi, lo = two_hilo_sum(hi, c)
c = tlo + lo
hi, lo = two_hilo_sum(hi, c)
return hi, lo
end
*)
operator +(const A,B : TDF64):TDF64;
var p1, p2:TDF64;
c:Double;
begin
  p1:=two_sum(a.hi, b.hi);
  p2:=two_sum(a.lo,

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

2020-09-27 Thread Florian Klämpfl via fpc-devel 

Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel:


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.


So we would need softfloat extended support. This is doable with one 
major obstacle: the "irrational" functions like ld, sin etc.: they need 
precise enough implementations for 80 bit (actually, just adding and 
using in the compiler 128 bit softfloat support would be even better). 
And this is probably something which is really hard. While I believe ;) 
I can solve most coding challenges, this is something I fear to touch :)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Nikolay Nikolov via fpc-devel 


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


Nikolay

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Florian Klämpfl via fpc-devel 

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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Nikolay Nikolov via fpc-devel 


On 9/27/20 7:03 PM, Martin Frb via fpc-devel wrote:

On 27/09/2020 09:34, Sven Barth via fpc-devel wrote:
Ben Grasset via fpc-devel > 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, ).
There's no known advantage of using a native win64 compiler, versus the 
win32 to win64 crosscompiler. There could be, if, while compiling very 
large programs, the 32-bit address space the compiler uses during 
compilation was exhausted (i.e. if the memory used by the compiler 
during compilation exceeds 4GB), and this happens AFAIK in C compilers, 
but, as far as we know, it just doesn't happen with FPC, because we 
don't use that much memory.


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)


A win64 to win32 crosscompiler is crippled, because it doesn't support 
80-bit extended float. That's why only a native win32 compiler is used 
to target win32.


Nikolay

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Martin Frb via fpc-devel 

On 27/09/2020 09:34, Sven Barth via fpc-devel wrote:
Ben Grasset via fpc-devel > 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).


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Nikolay Nikolov via fpc-devel 


On 9/27/20 10:48 AM, Florian Klämpfl via fpc-devel wrote:

As long as there is no generic 80 bit float support in the compiler, there is 
no need to discuss anything else.


Yes. And unlike some other compilers, we don't exhaust our 32-bit 
address space during compilation or linking of very large programs, so 
the fact that it is a cross-compiler should be irrelevant to the user.


Regarding ease of installation, we're planning to release the Windows 
version of FPC 3.2.2 as a single install package, that supports both 
32-bit and 64-bit Windows - it will include the 32-bit native and 32-bit 
to 64-bit crosscompiler, so it will be a single download for both Win32 
and Win64.


The necessary changes for the that are already committed to trunk, but 
it will need testing during the beta and release candidate phases.


Nikolay

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comment in math unit is a bit ambiguous?

2020-09-27 Thread Bart via fpc-devel 
On Sun, Sep 27, 2020 at 3:06 PM Florian Klämpfl via fpc-devel
 wrote:

> Thanks, fixed.

Thanks.


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comment in math unit is a bit ambiguous?

2020-09-27 Thread Florian Klämpfl via fpc-devel 

Am 18.09.20 um 22:50 schrieb Bart via fpc-devel:

Hi,

In unit math.pp you can find this comment:

510 
 
	{ returns random values with gaussian distribution }
511 
 
	function RandG(mean,stddev : float) : float;
512 
 
	function RandomRange(const aFrom, aTo: Integer): Integer;
513 
 
	function RandomRange(const aFrom, aTo: Int64): Int64;



The grouping of these functions together with the comment suggests (at 
least it did to me) that the comment above it applies to all 3 functions.

This is obviously not the case for the RandomRange functions.

I would propose to insert a single empty line between RandG and the 
RandomRange function, so it is more clear that the comment is only about 
the RandG function.


Thanks, fixed.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Florian Klämpfl via fpc-devel 

As long as there is no generic 80 bit float support in the compiler, there is 
no need to discuss anything else.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

2020-09-27 Thread Sven Barth via fpc-devel 
Ben Grasset via fpc-devel  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.

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel