fpu & extended precision - not as accurate as it should be?

[tthsqe]

It seems that the fpu instructions fmul and fdiv and not computing the results to the full extended precision - a 64 bit mantissa. It seems to be getting answers correct to 19 digits for the sin and cos of 1, but there are problems with simple multiplication and division. What is the point of being able to calculating sin and costo 19 digits when mul and div only work to 16 digits? The following code exemplifies what I mean:


fld1
fsincos

OK - sin and cos are correct to the full extended precision


fld1
fld st0
fadd st0,st0
fadd st0,st1 ; st0 = 3.0 , st1 = 1.0
fdivp st1,st0 ; st0 = 0.333333333333333315
fld st0
fmulp st1,st0 ; st0 = 0.111111111111111105

After the division here, the result to correct only to double precision. The final result of 1/9 is also correct only to double precision.

Also, loading thevalue of 1/3 correct to extended precision twiceand then multiplying still only gives the result of 1/9 correct only to double precision.

What is going on here?

[tthsqe]

Quoting - tthsqe

It seems that the fpu instructions fmul and fdiv and not computing the results to the full extended precision - a 64 bit mantissa. It seems to be getting answers correct to 19 digits for the sin and cos of 1, but there are problems with simple multiplication and division. What is the point of being able to calculating sin and costo 19 digits when mul and div only work to 16 digits? The following code exemplifies what I mean:


fld1
fsincos

OK - sin and cos are correct to the full extended precision


fld1
fld st0
fadd st0,st0
fadd st0,st1 ; st0 = 3.0 , st1 = 1.0
fdivp st1,st0 ; st0 = 0.333333333333333315
fld st0
fmulp st1,st0 ; st0 = 0.111111111111111105

After the division here, the result to correct only to double precision. The final result of 1/9 is also correct only to double precision.

Also, loading thevalue of 1/3 correct to extended precision twiceand then multiplying still only gives the result of 1/9 correct only to double precision.

What is going on here?

nevermind - WINDOWS had the control register set to 0x027F. It works as expected with 0x037F.

[TimP · Accepted solution]

Quoting - tthsqe

nevermind - WINDOWS had the control register set to 0x027F. It works as expected with 0x037F.

To be more precise, 32-bit programs running on 32-bit Windows are expected to set 53-bit precision mode for compatibility with Visual Studio run-time library. 64-bit Windows sets 53-bit precision mode before launching a .exe.
Intel compilers have a command line option /Qlong-double to set 64-bit precision mode. There is no run-time library support for that mode on Windows.
gcc programs, by default, will see 64-bit mode when running on 32-bit Windows, and 53-bit mode on 64-bit Windows.