Need Floating Extended support (FPC_HAS_TYPE_EXTENDED)

[hpw]

Hello 

did some tests with Lazarus 1.4.2 Win64 & fpc 2.6.4 and have seen that extended math type is not supported (most mult & add calculations are done using xmm...)

In most inc & pp units is the conditional FPC_HAS_TYPE_EXTENDED already included.

Question:

- how & where to add this FPC_HAS_TYPE_EXTENDED

- On Win64: How far is this FPC_HAS_TYPE_EXTENDED supported or tested

Thank you

Hp

[Thaddy]

On win64 there is *no* extended support nor will there ever be in the rtl. It defaults to interpreting extended as double, because afaik the ABI prescribes that. And that's probably because of the resolution of modern FPU's.
You are free to use any of the extended math libraries, however. There are many.
Or alternatively use win32. Or scaling: the full range +/- is rarely needed, so scaling would solve most real world issues.

This is by no means Windows only, btw.

[lagprogramming]

   I'm not sure a fpc developer needs third party libraries. I've never used win64, reason why I ask two questions.
   1. First of all, how can a user encapsulate code that's designed for 80bit size on a system that has a lower size per floating point value.
   For example the following code will be compiled in linux x86_64 but it won't compile in win64:

Code: [Select]

...
procedure store(const value: double);
procedure store(const value: extended);
...   The problem is that extended might become an alias for double. Is there a a define that can be used within {$ifdef ...} for the line containing "value:extended"? I don't think "win64" is good enough. "FPC_HAS_TYPE_EXTENDED" doesn't say anything regarding the size of the variable, does it!? I'm looking for something like "{$ifdef ExtendedSizeis80b}", or something with similar results.


   2. Taking a step further. Can the code above work by adding sfpux80(or softfpu) within "uses" and then somehow redeclaring the "extended" type within the project? Doing so would make win64 running applications use extended type with the size they expect. But this second step is usable only if the first one is done. It would be foolish to use software operations on a CPU that has usable hardware support for it.

[Jonas Maebe]

   For example the following code will be compiled in linux x86_64 but it won't compile in win64:

Code: [Select]

...
procedure store(const value: double);
procedure store(const value: extended);
...   The problem is that extended might become an alias for double. Is there a a define that can be used within {$ifdef ...} for the line containing "value:extended"? I don't think "win64" is good enough. "FPC_HAS_TYPE_EXTENDED" doesn't say anything regarding the size of the variable, does it!?.

That define means that the extended type has a different size than the double type. If you want to check for the size of 10 bytes, you can use {$if sizeof(extended) = 10}.

   2. Taking a step further. Can the code above work by adding sfpux80(or softfpu) within "uses" and then somehow redeclaring the "extended" type within the project?

There is no support yet for 80 bit extended in the FPC softfpu sources. I don't know if FPC currently supports mixed native and emulation support for fpu operations depending on the type, but I doubt it.

[Thaddy]

   The problem is that extended might become an alias for double.

No the problem is, extended is already an alias for double under win64, not just fpc.
80 bit float / win64 isn't supported by msvc or gcc either without adding additional math libraries.

As does Delphi64, where extended is also aliased to a double.

The logic behind it is that the previous 80bit float is supported on the 32bit intel instruction set, but NOT on the 64bit AMD/Intel instruction set, so you would have to revert to soft float anyway. Technically one could use the FPU87 instruction set but it will conflict with the more modern fp units in that they use the same register space, i.e. you can use 1 and loose the benefits of the other.

[lagprogramming]

   

There is no support yet for 80 bit extended in the FPC softfpu sources.

   I've noticed within softfpu the following subroutines for floatx80:

Code: [Select]

{$ifdef FPC_SOFTFLOAT_FLOATX80}
{*----------------------------------------------------------------------------
| Extended double-precision rounding precision
*----------------------------------------------------------------------------*}
var // threadvar!?
    floatx80_rounding_precision : int8 = 80;

function int32_to_floatx80( a: int32 ): floatx80;
function int64_to_floatx80( a: int64 ): floatx80;
function qword_to_floatx80( a: qword ): floatx80;
function float32_to_floatx80( a: float32 ): floatx80;
function float64_to_floatx80( a: float64 ): floatx80;
function floatx80_to_int32( a: floatx80 ): int32;
function floatx80_to_int32_round_to_zero( a: floatx80 ): int32;
function floatx80_to_int64( a: floatx80 ): int64;
function floatx80_to_int64_round_to_zero( a: floatx80 ): int64;
function floatx80_to_float32( a: floatx80 ): float32;
function floatx80_to_float64( a: floatx80 ): float64;
{$ifdef FPC_SOFTFLOAT_FLOAT128}
function floatx80_to_float128( a: floatx80 ): float128;
{$endif FPC_SOFTFLOAT_FLOAT128}
function floatx80_round_to_int( a: floatx80 ): floatx80;
function floatx80_add( a: floatx80; b: floatx80 ): floatx80;
function floatx80_sub( a: floatx80; b: floatx80 ): floatx80;
function floatx80_mul( a: floatx80; b: floatx80 ): floatx80;
function floatx80_div( a: floatx80; b: floatx80 ): floatx80;
function floatx80_rem( a: floatx80; b: floatx80 ): floatx80;
function floatx80_sqrt( a: floatx80 ): floatx80;
function floatx80_eq( a: floatx80; b: floatx80 ): flag;
function floatx80_le( a: floatx80; b: floatx80 ): flag;
function floatx80_lt( a: floatx80; b: floatx80 ): flag;
function floatx80_eq_signaling( a: floatx80; b: floatx80 ): flag;
function floatx80_le_quiet( a: floatx80; b: floatx80 ): flag;
function floatx80_lt_quiet( a: floatx80; b: floatx80 ): flag;
function floatx80_is_signaling_nan( a: floatx80 ): flag;
function floatx80_is_nan(a : floatx80 ): flag;
{$endif FPC_SOFTFLOAT_FLOATX80}
  Isn't floatx80 designed to act like the normal 80bit extended? With other words wasn't floatx80 designed be compatible with 80bit extended? They may have the same size but not the same content type.

[Jonas Maebe]

   

There is no support yet for 80 bit extended in the FPC softfpu sources.

   I've noticed within softfpu the following subroutines for floatx80:

Yes, it's there, but it's not yet supported because it doesn't fully work yet.

[lagprogramming]

   

There is no support yet for 80 bit extended in the FPC softfpu sources.

   I've noticed within softfpu the following subroutines for floatx80:

Yes, it's there, but it's not yet supported because it doesn't fully work yet.

   Thank you. I conclude that it's a work in progress and sooner or later users will be able to use 80bit sized extended variables on platforms that now just alias extended to double. Most probably this will be done upon individual user request(based on defines) and without using external libraries. This is very good.

[sam707]

https://gmplib.org

https://gmplib.org/manual/Float-Internals.html#Float-Internals

apparently using such library should bypass any 32, 64, 80... limitations. no known bug on last version (6.0)