...I havn't found document about the float accuracy of this dspic family...
You can check the XC16 User's Guide. It spells it all out.
For "normal" compiles float
data types are both 32-bit floats. On the other hand, long double
data types are 64-bit floats. (There is a compiler command-line switch that makes doubles 64-bits.)
Have you an idea why I have a big rounded mistake like that?
Go back to your workstation compiler and declare all of the variables to be floats rather than doubles and see what it gives. With GNU gcc, using floats rather than doubles, I get exactly the same output as you showed from the dsPIC. This compiler has 32-bit floats and 64-bit doubles.
Using floats instead of doubles, the output indicates the expected limits of 32-bit floating point precision: about six or seven decimal digits. Using 64-bit floats I expect about 16 significant decimal digit precision.
With XC16 version 1.11 I tried the following on a dsPIC33EP256GP506, and no special compiler switches:
long double valDouble1 = 0.0123456L;
long double valDouble2 = 12345.1L;
long double valDouble3 = 1.0;
valDouble1 += valDouble2;
valDouble1 += valDouble3;
printf("sizeof(float) = %d, sizeof(double) = %d, sizeof(long double) = %d\n",
sizeof(float), sizeof(double), sizeof(long double));
printf("1- Long Double : [%lf+%lf+%lf=%lf]\n",
0.0123456L, valDouble2, valDouble3, valDouble1);
sizeof(float) = 4, sizeof(double) = 4, sizeof(long double) = 8
1- Long Double : [0.012346+12345.100000+1.000000=12346.112346]
I have previously noted that the format specification for long doubles should be "%Ld" but XC16 doesn't like that. Printing long doubles with "%f" or "%lf" gives a warning, but results seem to show that the calculations are, at least, carried out with 64-bit floats.
post edited by davekw7x - 2013/09/25 14:56:15