Scali, Intel Itanium actually supports double-extended precision.


As a storage format? I thought it only had 81 bit internal precision, but loads/stores 32/64 bit floats only, not an 80-bit 'long double' that the x87 has.
Doesn't change anything I said though.
Posted on 2010-08-25 01:58:28 by Scali
Hi

By default it is set to double precision, so you are not using the full 80 bit FPU precision:
http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx


I think you are not correct here. Windows sets bits 9 and 8 of the FPU control word to 1 by default, wich means 80 bit precision.
You can read it here http://www.ray.masmcode.com/tutorial/fpuchap1.htm#cword or examine the control word on app entry by yourself.
On WinXP the value is set to 027Fh.
I guess that the link you provided only referes to the VS environment.

Biterider
Posted on 2010-08-25 03:47:10 by Biterider
The control word is indeed 027F.
But that means exactly _PC_53 (double precision).
If you look at the page you linked: 10 = 53 bits (REAL8)... And 10 binary is 2 in hex, and that's what you see in the high byte (it's stored in bits 8-9 of the control word, so the lowest two bits of the high byte).
Setting _PC_64 gives you 037F, and setting _PC_24 gives you 007F.
I also checked, it doesn't seem to matter whether you use a file compiled by the C compiler, or a 'raw' binary. You always get 027f. Looks like it is not a VC-thing, it's a Windows thing.
Posted on 2010-08-25 04:09:42 by Scali
Hi
Sorry... i misread the bin value from the CW. The PC field it is indeed 10y (53 bits - REAL8)

Biterider


PS: it must be a Windows thing since a finit instruction sets the CW to 37Fh (64 bits - REAL10) as described by Raymond.
Posted on 2010-08-25 04:21:07 by Biterider

PS: it must be a Windows thing since a finit instruction sets the CW to 37Fh (64 bits - REAL10) as described by Raymond.


Indeed.
Which demonstrates the portability that Microsoft envisioned with Windows NT. By defaulting to double precision, they can ensure that most other CPUs (or different extensions on x86 CPUs, such as SSE2+) can run software with the same precision. By not supporting long double in their compiler, they also avoid people writing non-portable C/C++ code (or .NET for that matter). Java is another example of an environment that simply doesn't allow anything other than the standard single and double precision IEEE754 standards.
Posted on 2010-08-25 04:47:50 by Scali
Scali,

ldfe/stfe instructions load/store double-extended precision floats from/to memory. And no, it doesn't change the rest of what you said.
Posted on 2010-08-25 09:38:15 by LocoDelAssembly
But what does the precision flag actually control?

I heard it was just FSQRT, with everything else done using double-extended / 80-bit.
Posted on 2010-08-28 04:39:49 by dila

But what does the precision flag actually control?

I heard it was just FSQRT, with everything else done using double-extended / 80-bit.


fsqrt and fdiv are pretty much the only instructions that run faster with lower precision (probably because they have early-out algorithms).
But the precision is affected on virtually all instructions (to enforce IEEE754 compatibility with these datatypes).
See the manual:
http://www.intel.com/Assets/PDF/manual/253665.pdf
The precision-control bits only affect the results of the following floating-point
instructions: FADD, FADDP, FIADD, FSUB, FSUBP, FISUB, FSUBR, FSUBRP, FISUBR,
FMUL, FMULP, FIMUL, FDIV, FDIVP, FIDIV, FDIVR, FDIVRP, FIDIVR, and FSQRT.
Posted on 2010-08-28 09:38:09 by Scali