In their _controlfp() documentation, Microsoft says,"On the x64 architecture, changing the floating point precision is not supported. If the precision co...Parameter Validation."
Does that mean it's not possible?
Please help, we need this.
We are currently evaluating whether or not to purchase the intel compiler and our purchase decision is based on what the answer to this question is. Is there someway I could get an answer from technical support on this issue? This might be more of a hardware question than a software one (i.e. does the x64 hardware support 80-bit precision mode for the fpu?). If there is a more appropriate forum for this question, please let me know.
80-bit precision mode for long double with Intel C++ is invokedwhen you set the long-double option in the compile line. As you will see in the Intel C++ documentation,80-bit long double is 16-byte aligned, so sizeof(long double) is 16.
All Windows and linux x64 compilers take SSE as the default mode, with all float and double data taken as SSE data types. In the early development of Windows x64, 80-bit x87 data were prohibited. Thisrestriction was relaxed by the time of full release, but Windows library support is lacking. In linux, long double support should be compatible with gcc.
80-bit long double will have the same issues with any x64 compiler; expressions with mixed data types float/long double or double/long doublecould be inefficient, due to the conversion between SSE and x87 data. If the gcc option -mfpmath=387 presents a partial solution, it would be at the expense of many of the usual optimizations for double and float data types, but there is no such option for icc.
So are you saying that on x64 on Windows it's not possible to get 80-bit intermediate precision with the intel compiler, but it is with gcc? Is there no way under windows to set the fpu into the 80-bit precision mode? Perhaps with inline assembly? Or it is a more drastic difference under x64 requiring a completely different set of instructions for fp operations?
You certainly can get 80-bit intermediate precision in your own code, even on Windows, with ICL. In-line assembly would not be needed,but it should work. While the default setting of precision mode for a Windows build is 53-bit, invokingICL -Qlong-double option for main() has the dual effect of setting precision mode back upto 64-bit, and keeping all long double variables at full precision.
Unlike 32-bit compilation, where all floating point arithmetic will be x87 if you don't set an SSE option, in a 64-bit Windows compilation you have no way to promote intermediate computations to long double, except by writing in casts or defining variables as long double, using a compiler such as ICL which supports this.
The icc linux option pair-mp -noftz, in the absence of vectorization, does switch over to x87. If you also set -long-double for main(), you will get full 80-bit arithmetic and the automatic extra precision evaluation of expressions. If you want to be sure of full precision in math functions, you would have to write in the long double versions. This is close to the effect you would expect from gcc -mfpmath=387. Unfortunately, it is not specifically supported as a work-alike for that gcc option.
There are no Microsoft library functions built to support 80-bit mode, neither 32- nor 64-bit. If you required those functions, you could write them yourself. If you examine values with printf(), you would expect to be able to view themonly rounded to double. The same effect occurs when you use gcc mingw. In these respects, your prognosis for 80-bit support is better on linux.
I have used both the Intel linux compiler option-mp -long-double -ftzand the gnu option -mfmath=387, to compare precision of calculations done with incidental extra precision against those with default 64-bit options of no extra precision. The effect is similar to what you get with 32-bit compilers in non-SSE mode.
If you wish to verify all these precision effects, you could try them on a benchmark such as Prof. Kahan's Paranoia, after fixing the bugs in the standard versions.