Hard FP compilation under GCC

You will need to add this -mfloat-abi=hard flag for ANY C source in your project that uses float functionality, not only the startup code.

Which from my research occurs when floating point types are mixed.

More exactly, softfp and hard differ in the way they pass arguments. The former uses core register and is thus compatible with the soft option, while the latter passes arguments in FPU registers.

BTW, you gain most in performance with changing from soft to softfp. Passing args in FPU registers (i.e. using the hard ABI), rarely makes much of a difference, at least much less than the soft-to-softfp step.

Thanks for the reply.

You will need to add this -mfloat-abi=hard flag for ANY C source

I should have been clearer, I am passing that argument to all my sources (ie. it's part of my CFLAGS make variable passed when compiling all files). I only included the error message and compilation command for my startup file because there are dozens of error messages which are identical but for different files.

Passing args in FPU registers (i.e. using the hard ABI), rarely makes much of a difference, at least much less than the soft-to-softfp step.

I may not bother with the hard option then, although I intend to perform some DSP operations via the CMSIS library. Would this be an instance that would benefit significantly from softfp > hard?

I assumed you have translated all source with this flag - but it was only an assumption ...

"c:\arm-gcc\bin\arm-none-eabi-ld.exe: error: src/system/startup_gcc.o uses VFP register arguments, bin/myproject.axf does not"

That bothers me. I would have assumed an AXF as the output of the linking process, not as input. What toolchain exactly you talk about ?

In other toolchains, this is a symptom for missing hard-ABI support.

I may not bother with the hard option then, although I intend to perform some DSP operations via the CMSIS library. Would this be an instance that would benefit significantly from softfp > hard?

As an example, I tried the FFT_bin example from the CMSIS DSP_lib both with softfp and hard. This made about 1% difference, which I deem insignificant. If your application makes heavy use of the FPU, it might be worth trying.

I would have assumed an AXF as the output of the linking process, not as input

My make file is very similar to this: https://github.com/Wollw/stellaris-launchpad-template-gcc/blob/master/Makefile

What toolchain exactly you talk about ?

https://launchpad.net/gcc-arm-embedded

I did have the impression that this specific toolchain supported hard-abi (it references it in the readme file), but perhaps I'm mistaken.

I had been talking about the CodeRed toolchain specifically.

See here : http://knowledgebase.nxp.com/showthread.php?t=3608

and here : http://support.code-red-tech.com/CodeRedWiki/CM4_FloatingPoint

Regarding launchpad.net - I would be surprised if it did not support this ABI version, but I haven't tried. About a year ago, I experimented with a summon-arm-toolchain (for STM32F4), and managed to build example projects wich used the hard-ABI. And this website declares itself as obsolete now, linking to launchpad.net ...

@Tim,

If changing from "soft" to "hard" you need also to link the right "hard" libraries. Did you done that? I presume you linked with some libraries - my settings are -lm -lc, and the path to libraries in this case is "/usr/local/gcc-arm-none-eabi-4_7-2012q4/arm-none-eabi/lib/armv7e-m/fpu/".

One mention: if changing, clean first the workspace (i.e. remove the previous .axf built with soft attribute)

Petrei

Excese me.

    Have the issue about hardfloat soluted ?

   I happended a link issue.How you solute your issue?

  My toolchain is  arm-none-linux-gnueabi-gcc( gcc version 4.3.3) ,

I write a simple expample :

main,c 

int main(int argc,char *argv[])

{
}

build :

arm-none-linux-gnueabi-gcc    -mfloat-abi=hard   -mfpu=vfpv3  main.c -o main

log :

/home/view/public/pengxc/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: error: /tmp/ccgEUDYW.o uses VFP register arguments, main does not
/home/view/public/pengxc/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: failed to merge target specific data of file /tmp/ccgEUDYW.o

Do you know reasion?

thanks!

Hi,

Some problems:

a) in embedded environment, such as Cortex-Mx, main should be without parameters - there is not an upper operating system to accept parameter passing to main

b) vfpv3 is for Neon if I am right, not for Cortex-M4;

c) arm-none-linux-gnueabi-gcc is optimized for Linux - you should have arm-none-eabi-gcc instead (I have seen on Internet some recommendations for -gnueabi- but seems the users had multiple problems with that).

Here are my settings for one project: 

Compiler settings:

Do toolchain must be  arm-none-eabi ? Is my  arm-v7a15v4r1-linux-gnueabi-gcc(version 4.7)  OK?

What are the differences of eabi and gnueabi ?  

My toolchain 's argument to '-mfpu' are fpa fpe2 fpe3 fpv4-sp-d16 maverick neon neon-fp16 neon-vfpv4 vfp vfp3 vfpv3 vfpv3-d16 vfpv3-d16-fp16 vfpv3-fp16 vfpv3xd vfpv3xd-fp16 vfpv4 vfpv4-d16. It  do not have   ' fpv4-sp-d16" .

Hi,

Well, depends how/where did you got this package - but I have doubts - you must be sure it is configured/compiled with all the bells and whistles needed for this - gnueabi package is known to be for Linux operating system. See this link - it is for the dedicated package - has some supplementary goodies (and it is written/maintained by ARM employees). fpv4-sp-d16 is mandatory.

 Petrei