Support of Extended or Quad IEEE FP formats

drMikeT · ‎01-15-2013

Hello,

I am using Composer XE for C/C++ (12.1 and 13) . I am trying to determine if the IEEE extended presicion (80 bits) and quad precision (128 bits) formats are supported in versions 12.1 or 13 of the C compiler.

I have been going over the manual but the only relevant information I ran into was one example using long double where the variable is called 80bit...

Should I assume long double in C translates to IEEE 80 bit extended precision format? Is quad (128 bits) supported? If yes, how? long long double?

Thanks

Michael

TimP · ‎01-15-2013

icc for linux should treat long double the same as the corresponding gcc. Without icc-specific not-fully-supported options, that's 80-bit, plus padding depending on whether it's ia32 or intel64 compilation mode.

The conversion between float or double and long double is efficient only in -mia32 mode (available only in the ia32 compiler), which excludes auto-vectorization.

icc linux practice for long double will not be the same as ICL for Windows

drMikeT · ‎01-15-2013

TimP (Intel) wrote:

icc for linux should treat long double the same as the corresponding gcc. Without icc-specific not-fully-supported options, that's 80-bit, plus padding depending on whether it's ia32 or intel64 compilation mode.

The conversion between float or double and long double is efficient only in -mia32 mode (available only in the ia32 compiler), which excludes auto-vectorization.

icc linux practice for long double will not be the same as ICL for Windows

Thank for the reply. I am refering to Intel64 mode on Linux. I saw that long double occupies 128 bits in C (v12.1). I assume that it corresponds to the IEEE Quad FP format, right ?

Looking at the man page for icc for the -fp-model option the arguments describing the precision of the intermediate results :

-fp-model source or /fp:source
                                This option causes intermediate results to be rounded to the precision
                                defined in the source code. It also implies keyword precise unless it is
                                overridden by a keyword from Group A.

              Intermediate expressions use the precision of the operand with higher precision, if any.

              long double: 64-bit precision; 80-bit data type; 15-bit exponent

refering to "long double" as if it corrsponded to the 80-bit "extended" precission IEEE format.

Further down the

-fp-model extended or /fp:extended
                                This option causes intermediate results to be rounded as follows:

              64-bit (extended) precision
              80-bit data type
              15-bit exponent

"extended "is defined as expected.

Since sizeof(long double) = 16 bytes, I assumed that for C long double corresponds to the IEEE Quad type, correct? Can we make it more clear in the documentation what IEEE format the long double actually corresponds to (Extended or Quad) and also make it clear if intermediate FP results are promoted to 128 bit quads or 80-bit extended?

Thanks

Michael

TimP · ‎01-15-2013

As I mentioned in another thread, icc for intel64 is consistent with the gcc -m64 scheme of padding 80-bit long double type out to 128 bits. It's an IEEE 80-bit extended, as long as you stick with documented options. You should be able to infer this from <float.h>.

drMikeT · ‎01-16-2013

TimP (Intel) wrote:

As I mentioned in another thread, icc for intel64 is consistent with the gcc -m64 scheme of padding 80-bit long double type out to 128 bits. It's an IEEE 80-bit extended, as long as you stick with documented options. You should be able to infer this from <float.h>.

I see ... Basically even for Intel64 target environmnet, long doubles are 80-bit extended padded to 128 bits? This brings up anoter Q: to use the 80-bit extended one has to use x87 instructions as SSE do not support anything > double, correct? Or is some emulation done by S/W?

Is there a plan to actually support the IEEE Quad precission for C/C++? For instance the 2 SIMD double ops could support 1 quad.

thanks

TimP · ‎01-16-2013

Yes, 80-bit long double is implemented by x87 instructions, hence may be slower when combined with double or float implemented in SSE2 than when everything is done by 32-bit compiler in non-SSE mode. I don't know of any plan to implement full C support for 128-bit IEEE format, although evidently ifort has support libraries. Neither type of long double works with vectorization, so there would not necessarily be any advantage for using icc over some other compiler supporting the long double data formats.

Bernard · ‎01-16-2013

>>>I see ... Basically even for Intel64 target environmnet, long doubles are 80-bit extended padded to 128 bits? This brings up anoter Q: to use the 80-bit extended one has to use x87 instructions as SSE do not support anything > double, correct? Or is some emulation done by S/W?>>>

As Tim said SIMD vector unit does not support 80-bit long double primitive type,so you are left with the option to use x87 FPU.If you are interested in speed of execution and less in precision I would advise you to use SSE2/3/4 instructions.

SergeyKostrov · ‎01-17-2013

Hi Michael and I'm sorry that I "joined the party" a little bit late... >>... >>I am trying to determine if the IEEE extended presicion (80 bits) and quad precision (128 bits) formats are >>supported in versions 12.1 or 13 of the C compiler. >>... >>I have been going over the manual but the only relevant information I ran into was one example using long double where the >>variable is called 80bit... >>... In case of an 80-bit expression You're mixing two different things. Let's say there is some C/C++ compiler that fully supports the long double and 10-bytes allocated for a variable when it is declared, like: ... long double ldVariable = 0.0L; ... If a developer checks a size of long double type, like: ... printf( "Number of bytes allocated: %d", sizeof( long double ) ); ... A result will be 10 bytes, that is 80 bits. However, a precision of a floating-point data type is a different thing and in that case it could be 64-bits, or 53-bits, or 24-bits, and it depends on how a Floating Point Unit ( FPU ) is initialized by default. For many modern and legacy C/C++ compilers a default precision for the double-precision data type is 53-bits.

TimP · ‎01-17-2013

Maybe this is nit-picking, but the hardware default for x87 is full 64-bit precision. 64-bit Windows sets it to 53-bit precision before handing over control to a .exe; 53-bit Windows expects the .exe to initialize 53-bit precision. The net result is that if you want 64-bit precision, you must set it yourself. The ICL option /Qpc80 is an option which should do that.

Intel compilers for linux apparently set 53-bit precision (default to -pc64), but this is at variance with the practice of other compilers. One of the stranger situations would be with gcc on Windows, where a 32-bit mode gcc program would start out in 64-bit precision mode if running on 32-bit Windows, but 53-bit precision if running on Windows X64. I don't know whether this may control the effective mode of gcc long double.

Bernard · ‎01-17-2013

>>>A result will be 10 bytes, that is 80 bits. However, a precision of a floating-point data type is a different thing and in that case it could be 64-bits, or 53-bits, or 24-bits, and it depends on how a Floating Point Unit ( FPU ) is initialized by default.>>>

In case of IEEE 754-2008 128-bit quadruple precision binary number will have 112-bits of precision.

SergeyKostrov · ‎01-17-2013

Michael, Let me know if you need a C/C++ example on how a precision of floating-point data types could be controlled.