Which bitness first ?

[BrunoK]

Which is perfecrly possible with softfloat.... and that is supported. It is also possible with some Florian specific tricks on x86_86-win64.(this is hardly documented, but works)
It is developed.

Softfloat is still missing a few basic math routines like exp or ld that are necessary for complete coverage and thus consistent compilation from non-Extended targets to those that have Extended. Also the compiler currently does not support softfloat inside itself correctly, so it wouldn't work either currently.

Even if it existed for the x86_64, softfloat for extended would probably be much slower than FPU.

As far as I know, i386 using the FPU for the Currency type doesn't overflow registers when the result of the multiplication is wihin the Currency domain but x86_64 gives wrong results when Currency*Currency overflows 64 bit during the Gaussian division by 10'000.

The fact that x86_64 does not use the FPU in windows implies that mathematics for which the Extended FPU was created cannot be done with FPC x86_64. Maybe that's the type of math marcov mentionned.
 See https://en.wikipedia.org/wiki/IEEE_754#Design_rationale

[Thaddy]

Of course it is slower, but it is being worked on and the compiler can not even be compiled with softfloat disabled. PascalDragon's answer was therefor a surpise to me.
BTW for historical reasons: TP already supported softfloat, as did TB, Bob Zale wrote that..for both.
(and you can always compile with extended enabled hardware for Windows64, although that is a bit of a trick and not officially supported)
It is basically only win64 that is affected because of the abi.
But there are more platforms, just mentioned win64.

It will always be slower because it is an emulation, so that part of your argument makes no sense.

[BrunoK]

(and you can always compile with extended enabled hardware for Windows64, although that is a bit of a trick and not officially supported)

How ?

I would like to test if it solves the bad out of domain errors for Currency's during multiplication.

[avra]

Which is perfecrly possible with softfloat.... and that is supported. It is also possible with some Florian specific tricks on x86_86-win64.(this is hardly documented, but works)
It is developed.

Softfloat is still missing a few basic math routines like exp or ld that are necessary for complete coverage and thus consistent compilation from non-Extended targets to those that have Extended. Also the compiler currently does not support softfloat inside itself correctly, so it wouldn't work either currently.

Long time ago I have done exp() and ldexp() in my fast fix64 (s31.32 fixed point library) implementation for AvrCo embedded pascal. Easy calculations but I can share code if that could help. Even had an idea to adapt fix64 for FreePascal and basic math worked but did not have time yet to proceed further.

[Thaddy]

(and you can always compile with extended enabled hardware for Windows64, although that is a bit of a trick and not officially supported)

How ?

I would like to test if it solves the bad out of domain errors for Currency's during multiplication.

the exact instructions are on the fpc-devel mailing list archives. It is about 5-6 years old and the instructions are from Florian himself..
Warning: the compiler is then not  Windows ABI standards compliant so it may cause many other problems. It is just for number crunching maniacs that need 80 bit precision instead of 64 for extended on win64. I do not use it any longer but I did try it and it works.
Just in case: you need to know how to build from source and there is no support whatever for it. So not even ask for support. It can be done, but if it is wise is another matter. (there is not a release of that anywhere, not even a preview, just build instructions.)

And no, it won't solve your currency problem, although I would like to see where it errors for you because the currency type is a well defined standard to which fpc (and delphi) complies.
Otherwise I would have to give at least 25 years of my pension plan back..
I suppose you never heared of banker's rounding? That can explain it. the difference between plain floating point operations and currency operations can be quite substantial but should even out eventually. Both types of calculations are inaccurate..

[dbannon]

On my 6 year old linux 64bit laptop, of course I develop 64 bit first. Later I cross compile to Linux 32bit, Windows 32 and 64, Arm 32 and 64 and then test each (except Win32) on a real platform.  My Windows package has both 32 and 64 bit binaries so I cannot tell who downloads what but not had a win32 specific complaint yet !

In Windows, I have an only occasionally used 64 bit fpc/lazarus install, have never needed 32bit windows development platform, I guess ignorance is bliss !

Mind you, I'd have a pink fit if my app used even a significant part of 2G ram, its intended to run in the background so minimizing memory consumption is important to me.

Davo

[Thaddy]

Davo,
remember writing TSR's?

[BrunoK]

(and you can always compile with extended enabled hardware for Windows64, although that is a bit of a trick and not officially supported)

How ?

I would like to test if it solves the bad out of domain errors for Currency's during multiplication.

[/quote}

the exact instructions are on the fpc-devel mailing list archives. It is about 5-6 years old and the instructions are from Florian himself..

Never found them.

And no, it won't solve your currency problem, although I would like to see where it errors for you because the currency type is a well defined standard to which fpc (and delphi) complies.

On Windows, the code below does not give the same results  on i386 and x86_64.

Code: Pascal  [Select][+][-]

1. program Project1;
2. uses
3.   Math;
4. var
5.   vSqrRootDbl: double;
6.   vCur, vCurRes: currency;
7. begin
8.   vSqrRootDbl := Sqrt(High(Currency));
9.   vCur := Trunc(vSqrRootDbl); // vCur^2 result is in Currency domain !
10.   vCurRes := vCur * vCur;     // but vCur*vCur is wrong due to gaussian division
11.                               // overflow for the divide by 10000. This works on
12.                               // I386 platform because of  the use of the FPU.
13.   WriteLn(High(Currency), ' ', vSqrRootDbl, ' ', vCur, ' vCur * vCur=', vCurRes );
14.   if Trunc(vSqrRootDbl*vSqrRootDbl) <= High(Currency) then
15.     WriteLn('vSqrRootDbl*vSqrRootDbl=',Trunc(vSqrRootDbl*vSqrRootDbl),' is <= High(Currency)', High(Currency));
16.   ReadLn;
17. end.  

[dbannon]

Davo,
remember writing TSR's?

Indeed. I remember writing one from scratch with the help of a book on assembler. I was so pleased with it that I made a framework around it for "general use". But it used so much memory, almost useless.

But to my surprise it kept popping up on the lists.  I am very glad those days are gone !

("640K should be enough for any application .....")

Davo

[PascalDragon]

Which is perfecrly possible with softfloat.... and that is supported. It is also possible with some Florian specific tricks on x86_86-win64.(this is hardly documented, but works)
It is developed.

Softfloat is still missing a few basic math routines like exp or ld that are necessary for complete coverage and thus consistent compilation from non-Extended targets to those that have Extended. Also the compiler currently does not support softfloat inside itself correctly, so it wouldn't work either currently.

Even if it existed for the x86_64, softfloat for extended would probably be much slower than FPU.

That's not relavant, cause the choice is either accurate compilation for targets supporting Extended from targets not supporting it (which is what we desire), inaccurate compilation (which we want to avoid) and no compilation (which is the current situation).

Of course it is slower, but it is being worked on and the compiler can not even be compiled with softfloat disabled. PascalDragon's answer was therefor a surpise to me.

It's not that it can't be compiled, it's that constants in cross compiled code will have inaccurate values and thus essentially a cross compiled binary will behave differently from a natively compiled one which is a no-go.

It is basically only win64 that is affected because of the abi.
But there are more platforms, just mentioned win64.

It affects all targets that don't support Extended to compile to targets supporting to Extended. The set of targets that don't support Extended is in fact larger than the set that does.

Which is perfecrly possible with softfloat.... and that is supported. It is also possible with some Florian specific tricks on x86_86-win64.(this is hardly documented, but works)
It is developed.

Softfloat is still missing a few basic math routines like exp or ld that are necessary for complete coverage and thus consistent compilation from non-Extended targets to those that have Extended. Also the compiler currently does not support softfloat inside itself correctly, so it wouldn't work either currently.

Long time ago I have done exp() and ldexp() in my fast fix64 (s31.32 fixed point library) implementation for AvrCo embedded pascal. Easy calculations but I can share code if that could help. Even had an idea to adapt fix64 for FreePascal and basic math worked but did not have time yet to proceed further.

64-bit fixed point does not help. We need 80-bit floating point support routines.