EmbDev.net

Forum: ARM programming with GCC/GNU tools Toolchain with standard IEEE floating point emulation


von Andrea M. (amazzoleni)


Rate this post
useful
not useful
I need to compile code using the standard IEEE floating point format,
i.e. without the mixed big/little endian format used by the default FPA
floating point format for double types.

On my understanding this requires to compile with the VFP format with
the options "-mfpu=vfp -msoft-float"

The problem is that all the libraries of WinARM become incompatible:

...>arm-elf-ld "-LC:\WinARM\lib\gcc\arm-elf\4.1.1" -Tte
st.ld -g test.o -l gcc -o test.exe
arm-elf-ld: ERROR:
C:\WinARM\lib\gcc\arm-elf\4.1.1\libgcc.a(_muldivdf3.o) uses F
PA instructions, whereas test.exe does not
arm-elf-ld: ERROR:
C:\WinARM\lib\gcc\arm-elf\4.1.1\libgcc.a(_muldivdf3.o) uses h
ardware FP, whereas test.exe uses software FP
arm-elf-ld: failed to merge target specific data of file
C:\WinARM\lib\gcc\arm-e
lf\4.1.1\libgcc.a(_muldivdf3.o)

Does exist a Windows toolchain compatible with this format ?
If not, which is the simpler way to compile it ?

von Clifford S. (clifford)


Rate this post
useful
not useful
The premise is incorrect since IEEE 754 does not specify byte order.

If you want VFP libraries you will have to rebuild the Newlib library
from source with "-mfpu=vfp -msoft-float". Which is fairly
straightforward (I have done just that in-order to support the NXP3180
chip).

However, it seems a sledgehammer to crack a nut somewhat. If you are
exchanging data between systems with different byte ordering, it is
simpler and more portable
to write data exchange routines that do that for you as necessary.

Clifford

von Clifford S. (clifford)


Rate this post
useful
not useful

von Andrea M. (amazzoleni)


Rate this post
useful
not useful
Clifford Slocombe wrote:
> The premise is incorrect since IEEE 754 does not specify byte order.
Thanks for the clarification.

> If you want VFP libraries you will have to rebuild the Newlib library
> from source with "-mfpu=vfp -msoft-float". Which is fairly
> straightforward (I have done just that in-order to support the NXP3180
> chip).
I've already recompiled NEWLIB. But as you can see on the previous
message the error is linking libgcc, which is part of the gcc
distribution. So I suppose I need to compile the whole toolchain.

Where do I can find the exact script used to compile WinARM ?

> However, it seems a sledgehammer to crack a nut somewhat. If you are
> exchanging data between systems with different byte ordering, it is
> simpler and more portable
> to write data exchange routines that do that for you as necessary.
Yes. I agree. I need this for a special development environment
distributed between a PC and an ARM. To make the life easier for the
users we are trying to use the same format. More work for me but less
work for a lot of users.

Bye

von Clifford S. (clifford)


Rate this post
useful
not useful
Andrea Mazzoleni wrote:
> I've already recompiled NEWLIB. But as you can see on the previous
> message the error is linking libgcc, which is part of the gcc
> distribution. So I suppose I need to compile the whole toolchain.
>
> Where do I can find the exact script used to compile WinARM ?
>
When I rebuilt newlib for VFP support, I did not need to to rebuild
anything else, but I'll have to take a look to see what I did to achieve
that. I'll get back to you.

Andrea Mazzoleni wrote:
> Yes. I agree. I need this for a special development environment
> distributed between a PC and an ARM. To make the life easier for the
> users we are trying to use the same format. More work for me but less
> work for a lot of users.
I am not sure how it makes life any easier or harder for users - you
simply provide library routines at one end of the other of the
communication to massage teh data appropriately. Another approach is
simply to exchange the data as ASCII string representations or perhaps
BCD and implement conversions. All this could be transparent to users
because it would be behind the interface that you define that merely
provides or accepts native floating point values. Your solution would
make me very nervous. How is the data exchanged between the two systems?

Clifford

von Clifford S. (clifford)


Rate this post
useful
not useful
Clifford Slocombe wrote:
> When I rebuilt newlib for VFP support, I did not need to to rebuild
> anything else, but I'll have to take a look to see what I did to achieve
> that. I'll get back to you.
>
OK, I'm back.


Now bearing in mind that I used an earlier GNU toolchain version, and
that the target had a real hardware VFP (which may have been the reason
for success of course), my make file contains the following macros
controlling the build, not all of which will be applicable to your
problem or target, but may help:

CLIBPATHS = -L$(WINARM_TOOLS_ROOT)/lib/gcc/arm-elf/4.0.2/fpu/interwork \
            -L$(WINARM_TOOLS_ROOT)/arm-elf/lib/fpu/interwork
CFLAGS   =  -v -O3 -ftree-vectorize -Wall -Werror -Wformat -c
$(INCLUDES) -mfpu=vfp -mfloat-abi=softfp -mhard-float -mapcs-frame
-mthumb-interwork -mlittle-endian -mcpu=arm926ej-s $(MACROS)
-Wa,-al,-ah,-as,-L > $(basename $(notdir $@)).lst
AFLAGS   = -gdwarf2 -mcpu=arm926ej-s -mlittle-endian -mthumb-interwork
LFLAGS   = -nostdlibs --start-group -lc -lm -lgcc -lstdc++ --end-group
-e start -T $(LDSCRIPT) -Map $(PROJNAME).map

Now my guess is that no VFP emulation code is not provided in the GNU
toolchain, so rebuilding it may not help. I only had it work because the
target has VFP hardware, so no emulation code was linked. This is a
reasonable assumption IMO since if you are using software floating point
one emulation is as good (or bad) as another - it is still going to be
horribly slow.

See the documentation for -msoft-float and -mfloat-abi at
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/ARM-Options.html#ARM-Options

I still think you are making this far harder than it need be. Perhaps if
you provide more information about the requirements a better solution
could be proposed?

Clifford

von Andrea M. (amazzoleni)


Rate this post
useful
not useful
Clifford Slocombe wrote:
> Now bearing in mind that I used an earlier GNU toolchain version, and
> that the target had a real hardware VFP (which may have been the reason
> for success of course)

I got a partial success recompiling the toolchain adding the specific
GCC configuration option "--with-fpu=vfp --with-float=soft" documented
in the gcc INSTALL files.

Using the resulting libgcc.a/libm.a/libc.a with the standard WinARM
compiler seems to work. I tried some FPU operations from additions and
multiplications (libgcc) to the more complex trigonometric functions
(libm) and all seems correct.

My next step will be to try to change the MULTILIB configuration to
directly generate the required libraries in the standard toolchain
compilation. But at least I have a working solution.

> I still think you are making this far harder than it need be. Perhaps if
> you provide more information about the requirements a better solution
> could be proposed?
The data is supposed to be exchanged in raw memory format. For example,
an entire C struct can be shared. If we can use the same memory format
the user doesn't need to add context information at the data.

Thanks for you support.

von Clifford S. (clifford)


Rate this post
useful
not useful
Andrea Mazzoleni wrote:
> The data is supposed to be exchanged in raw memory format. For example,
> an entire C struct can be shared. If we can use the same memory format
> the user doesn't need to add context information at the data.
>
Now you really are scaring me! ;-)

Structure packing, word alignment, byte ordering, and floating point
format are all compiler/architecture dependent and are likely to differ
between any two systems. For the unwary, there are a whole heap of
problems awaiting you if you choose that route. Not least your code may
break simply by being compiled with different options or on a different
compiler (at either end of the link). This is much harder to manage than
simply writing a portable exchange format.

Good luck with it in any case.

Clifford

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.