Re: floating point functions returning bogus results on ARM target?

[Federico Terraneo <fede dot tft at hotmail dot it>]

Andreas Müller wrote:
> Hello,
>
> I'm  trying  to get newlib to compute interesting stuff on an NXP
> LPC2138, which is an ARM7TDMI-S  based  microcontroller.
Hi, I'm not a newlib developer, just an user. But I've worked for a 
couple of years with the LPC2138, so maybe I can give you some advice.

> I  have
> compiled  gcc-4.3.4  and newlib-1.18.0 on an i386 Linux host, the
> target is arm-elf. The compiler seems to work OK, at least I have
> successfully  ported  FreeRTOS,  which works fine. Integer arith-
> metic seems to be ok, too. However, floating point stuff seems to
> be completely off.  I wonder whom to blame: the compiler, newlib,
> or something I did not think about?
>
> The following code tests whether x - floor(x) is smaller than  1,
> which  it  should  always be by the definition of the floor func-
> tion:
>
>         double  x = 1234567./1024., z;
>         while (1) {
>                 x += 0.1;
>                 z = x - floor(x);
>                 if (z >= 1) {
>                         putchar('+');
>                 } else {
>                         putchar('-');
>                 }
>         }
>
> When I run this code on a Linux system, it outputs only -  signs,
> as  expected.   On the ARM target, with newlib, I get a nice pat-
> tern of + and -. It starts off like this
>
>     --++---++---++---++---++---++---++---++---++---++---++---++---++
>
> so 2 out of 5 computations fail the test.
>
> I did a similar test for the values of the sin(x) function, which
> should never exceed 1: again 2 out of 5 numbers fail the test.
>
> So  what  am  I missing here? Should I have built the compiler or
> newlib differently? I used the  following  configure  command  to
> build newlib and the compiler:
>
>         ../newlib-1.18.0/configure --target=arm-elf 
--prefix=/usr/local/arm \
>             --enable-interwork --enable-multilib 
--enable-target-optspace \
>             --with-float=soft
>         ../gcc-4.3.4/configure --target=arm-elf --prefix=/usr/local/arm \
>             --enable-interwork --enable-multilib 
--enable-languages="c,c++" \
>             --enable-target-optspace --with-float=soft --with-newlib \
>             --with-headers=../newlib-1.18.0/newlib/libc/include/ 
--disable-nls
>
> I  do  have  other problems with newlib on the ARM, e.g. that the
> processor goes into an abort state as soon as I try to use printf
> with a float or double (no problem with integers), but that seems
> to be a well known problem having to do with  printf's  excessive
> demands  on  the stack or heap (which the LPC2138 simply does not
> have). This however prevents me from posting numeric results.

At first, it looks me you have some bug in your implementation of 
syscalls (especially _sbrk_r, the one used by malloc()), or your startup 
script (check that the .data section is copied correctly from flash to 
ram, and that .bss is cleared) or the linker script (is the address of 
start-of-ram and end-of-ram correct?).
The LPC2138 is surely capable of handling floating point, *including* 
printing results via printf through a serial port, so that's why I'm 
pointing in this direction.
To test this, try with a known good set of these files (startup script, 
linker script and syscalls). You can try the one I use here 
(http://www.webalice.it/fede.tft/cpp_on_microcontrollers_tricks/template.zip)
They're designed for C++, but you can start by writing your test code in 
main.cpp, and later even modify them to be used with plain C.

Another option if the above fails, is to compile everything again 
without the --enable-target-optspace. I found it to produce wrong code 
in some cases, and in general the small reduction in code size and large 
performance penalty is usually not worth it. To optimize for code size I 
usually use -Os when compiling and just that.

Hope this helps.
TFT

>
> Mit herzlichem Gruss
>
>                                         Andreas Müller
>
> --
> Andreas Müller
> HSR Hochschule für Technik Rapperswil
> Oberseestrasse 10, Postfach 1475, CH-8640 Rapperswil
> Tel: 41 55 222 41 11   Email: andreas.mueller@hsr.ch
>
>
>
>