softfp seems to use software floating point code

Asked by Isaac Charles

I am using arm-none-eabi-gcc 4.8_2014q2. I have a project for the STM32F4 processor (which has hardware fp) -- cortex M4f. I am compiling and linking with --mfpu-fpv4-sp-d16 -mfloat-abi=softfp. The documentation says this will use software calling conventions but hardware fp within the functions it calls. That is exactly the trade-off I am hoping for.

In looking at the disassembly, the r registers are loaded with the values to be divided or multiplied, as expected, and then __aeabi_fdiv or __mulsf3 are being called. So far so good. However, if I follow the trace further, it turns out that those functions, even in lib/gcc/arm-none-eabi/4.8.4/armv7e-m/softfp/ are full software divide and multiply. The operands are never placed in s registers. The hardware fp unit is never used.

In libgcc.a, I see that there /are/ functions that use hardware fp. Just not the ones gcc is choosing to do the multiply and divide. Is there some trick to tell the system, "no, really, use floating point hardware"? Or was the "hardware fp with software calling conventions" not what it sounds like?

Thanks!

Question information

Language:
English Edit question
Status:
Answered
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Terry Guo (terry.guo) said :
#1

2014年9月25日 上午6:02于 "Isaac Charles" <email address hidden>写道:
>
> New question #254968 on GCC ARM Embedded:
> https://answers.launchpad.net/gcc-arm-embedded/+question/254968
>
> I am using arm-none-eabi-gcc 4.8_2014q2. I have a project for the
STM32F4 processor (which has hardware fp) -- cortex M4f. I am compiling
and linking with --mfpu-fpv4-sp-d16 -mfloat-abi=softfp. The documentation
says this will use software calling conventions but hardware fp within the
functions it calls. That is exactly the trade-off I am hoping for.
>
> In looking at the disassembly, the r registers are loaded with the values
to be divided or multiplied, as expected, and then __aeabi_fdiv or __mulsf3
are being called. So far so good. However, if I follow the trace further,
it turns out that those functions, even in
lib/gcc/arm-none-eabi/4.8.4/armv7e-m/softfp/ are full software divide and
multiply. The operands are never placed in s registers. The hardware fp
unit is never used.
>
> In libgcc.a, I see that there /are/ functions that use hardware fp. Just
not the ones gcc is choosing to do the multiply and divide. Is there some
trick to tell the system, "no, really, use floating point hardware"? Or
was the "hardware fp with software calling conventions" not what it sounds
like?
>
> Thanks!
>
> --
> You received this question notification because you are a member of GCC
> ARM Embedded Developers, which is an answer contact for GCC ARM
> Embedded.

Thanks for reporting. It is certain that we should use fpu for softfp and
hard. I will check our libraries and get back to you later.

BR,
Terry

Revision history for this message
Terry Guo (terry.guo) said :
#2

The libraries under paths like gcc-arm-none-eabi-4_8-2014q2/lib/gcc/arm-none-eabi/4.8.4/armv7e-m/softfp are so called compiler helper libraries which are designed to be used by compiler internally. Those libraries are not part of C libraries. They work as an alternative way to implement some operations from user C code. For example, if there is a div operation in user code but the target hasn't hardware div instruction , then compiler will generate a call to helper function from those libraries to simulate div operation in pure software way. But if target does has hardware div instruction, then such call to helper function shouldn't be used.

The libraries under paths like gcc-arm-none-eabi-4_8-2014q2/arm-none-eabi/lib/armv7e-m/softfp are C libraries. They work in different way from the above libraries. Those C libraries should use hardware feature as much as possible. So if target has hardware FPU DIV instruction, then it should be used for softfp and hard ABI.

For the case you mentioned, I think __aeabi_fdiv shouldn't be used because cortex-m4 fpu has vdiv instruction. But I need more information to analyze the issue. So would you please provide a reduced case and involved compiler options?

Can you help with this problem?

Provide an answer of your own, or ask Isaac Charles for more information if necessary.

To post a message you must log in.