[En-Nut-Discussion] Problem with ARM floating point, again

[Bob Wirka]

Hello,

I'm having issues with printf("%f") on my AT91SAM7X512 platform (using ethernut-4.10.3). We're using the Codesourcery compiler (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-51)).


I believe this is an alignment issue with va_arg(). I'll try to attach 4 screen shots (two pairs) showing different results with the same code; the only difference being that the failure occured after some additional code was included in the build.The first shot of each pair 
shows the source code being executed and the output. The second shot 
of the pair shows the debugger after executing va_arg(). The first two show successful operation, the second two show failure. You can see the result of the va_arg() call in the debugger watch window.


The code attempts to execute "printf("testing %.03f\n" , fval);", where 'fval' is 4.08.


Essentially, the call to va_arg(ap , double) at line 449 in putf.c can return an incorrect value. The function _dtoa_r() does not seem to be the culprit, at least in my case.

When printf fails, it prints -0.000 instead of 4.08 because the call to va_arg(ap , double) returns -5.3102737417063065e-315.

It would appear that when additional (not executed) code is included in the build, the failure will occur. I've seen this kind of flaky behaviour before in a linux driver; the problem there was cured by adding alignment pragmas.

I hope this helps. This has been a real problem.

Best,

Bob Wirka
Realtime Control Works
Janesville, WI



________________________________
 From: Harald Kipp <harald.kipp at egnite.de>
To: Ethernut User Chat (English) <en-nut-discussion at egnite.de> 
Sent: Wednesday, January 30, 2013 8:31 AM
Subject: Re: [En-Nut-Discussion] Problem with ARM floating point, again
 

Me again,

On 30.01.2013 09:52, Harald Kipp wrote:
> a user reported, that printf output of a double float fails on SAM7X
> with Nut/OS 4.10, using the latest Yagarto toolchain.

What I learned so far is, that the problem still exists with a number of
previous releases of the Yagarto toolchain and probably with Linux
toolchains as well. It looks like an alignment problem with newlib's
_dtoa_r function.

Printing floats on Nut/OS for ARM is considered broken until further
notice. If you want to print float values, convert them to integer
first, e.g.

double val = 15.1;
int d = val * 1000;
printf("Float: %d.%03d\n", d / 1000, d % 1000);

I remember similar problems on the AVR platform. IMHO, the best solution
is to provide our own dtoa function. But that's a challenge. All
existing code I found so far is based on the ancient AT&T (later Lucent)
code.

Regards,

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion