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 ?
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
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
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
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
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.
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
Watch this topic
Disable multi-page viewPlease 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
Log in with Google account
No account? Register here.