double precision size

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

double precision size

828 Views
adyr
Contributor V

Hi,

 

Is there support (or going to be support) for printing double precision numbers in KSDK 1.2 / MQX?

 

I am building with IAR and I generated the code with KDS 3.0.

 

In the fp_prv.h file it mentions about IEEE 754 single-precision format with an 8 bit exponent, etc but I can't see any mention of double-precision. My application requires the use of double in a couple of places but when I try to use sprintf the stack gets corrupted and the process crashes. This is because double has 11 bit exponent and 53 digits so the buffer is not big enough during the while(intpart != 0) loop in _cvt in fp_prv.c and no check is made in the loop for the pointer going out of bounds. If I change the definition of NDIG to 1080 ( max(E) = 1023 and max(F) = 53 ) then everything seems to be OK.

 

Best regards,
Adrian.

Labels (1)
0 Kudos
2 Replies

521 Views
santiago_gonzal
NXP Employee
NXP Employee

Hello,

Cortex M4 does not support double precission floating points. It is not an MQX/KSDK limitation, but a limitation of the core/floating point unit.

Cortex M7 do have a double precission floating point unit.

Regards,

Santiago

0 Kudos

521 Views
adyr
Contributor V

Thanks for getting back to me Santiago but I have to dispute your logic. I agree the M4 may not support hardware acceleration of double but the software libraries do support double. Thankfully everything works fine if I increase the size of NDIG to 1080, even though it has a big impact on stack space as the buffer is allocated on the stack. It feels like the libraries have been updated but either that #define was missed or a validation has been left out in _cvt to ensure it doesn't overrun the supplied buffer for larger exponents.

Generally I avoid using any floating point numbers if possible but sometimes needs must.

If anyone does need to use printf type functions with double and find it crashes their system then change the #define NDIG in fp_prv.h to 1080 and or change the line 153 in fp_prv.c form:

     while (intpart != 0)

to

     while ((intpart != 0) && (p1 >= buf))

The second fix alone will stop the crash but will not allow numbers with exponents > 127 or < -127 to print correctly. Hopefully Freescale will provide an official fix to the stack corruption in a future update.

Best regards,

Adrian.

0 Kudos