[U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Måns Rullgård mans at mansr.com
Sat Feb 19 19:36:33 CET 2011


Albert ARIBAUD <albert.aribaud at free.fr> writes:

> Le 19/02/2011 15:34, Måns Rullgård a écrit :
>> Albert ARIBAUD<albert.aribaud at free.fr>  writes:
>>
>>> Le 19/02/2011 15:06, Alexander Holler a écrit :
>>>> Am 19.02.2011 14:51, schrieb Albert ARIBAUD:
>>>>> Le 19/02/2011 14:25, Måns Rullgård a écrit :
>>>>>
>>>>>>> So whats the reasoning to use -msoft-float as it is currently done? To
>>>>>>> confuse people? ;)
>>>>>>
>>>>>> I guess it's there to make sure no floating-point instructions make it
>>>>>> into u-boot, even though floats are not used in the code. Perhaps
>>>>>> someone was paranoid.
>>>>>
>>>>> I think also that there is no choice but to have a float option for ARM
>>>>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with
>>>>> the 'soft' calling conventions), because the C compiler does not allow
>>>>> 'no floats', and anyway the C language *requires* to have some sort of
>>>>> float support.
>>>>
>>>> As it is on every platform.
>>>
>>> Indeed.
>>>
>>>>> Actually if you don't specify any float option, the C toolchain will
>>>>> choose one, which is just the same in the end: *some* float option is
>>>>> chosen.
>>>>
>>>> Every compiler has dozens of options which are set to a default value.
>>>
>>> Granted. But not all of them relate to hardware which may or may not be
>>> available.
>>>
>>>>> And since some option must be chosen, I prefer that U-Boot make the
>>>>> explicit decision, and choose soft float for the reasons I already
>>>>> exposed.
>>>>
>>>> I don't see any reason to explicitly set an option for something which
>>>> isn't used, but I know of many reasons to avoid such. ;)
>>>
>>> At least there is one reason for having -msoft-float even though no
>>> floating point should be used in U-Boot : it helps catching cases where
>>> some code in U-Boot tries to use hard float. :)
>>
>> There is one further complication here.  If the compiler was built with
>> -mfpu=neon as default, it might emit neon instructions for pure integer
>> code.  For the purpose of this discussion, such instructions should
>> still be regarded as floating-point since they are tied to the VFP.
>> Such code generation is disabled by -msoft-float.
>
> Thanks for indicating this. If I paraphrase this correctly, some 
> toochains would generate floating instructions for integer if both 
> -mfloat-abi=hard and -fmpu=neon were specified or were the default.

-mfloat-abi of hard or softfp both allow neon instruction to be emitted.

> I don't see this as a worrying matter though, because I suspect that 
> toolchains that have -mfpu=neon will have -mfloat-abi=hard as well and 
> target cpus that have hw floating point capabilities, where such float 
> instructions would cause no problem.

The issue is not one of hardware availability.  Using the VFP/NEON unit
at all requires additional support beyond simply using the instructions.

Firstly, the coprocessor must be enabled, which although a trivial
operation does add complexity and maintenance burden.

Secondly, any code run in an interrupt context must be somehow arranged
to be free of VFP/NEON code, or the VFP context must be saved and
restored around interrupt handlers.  The latter is a bad idea since it
significantly slows interrupt handling.  This leaves us with the former
option, and if some code must be VFP-free, that requirement might as
well be extended to all code with no additional burden.

The simplest way to make sure no VFP or NEON instructions are used is to
pass -msoft-float to the compiler.  Since linking to libgcc is an error
in u-boot, ABI compatibility with it is of no concern.

To summarise, I think using -msoft-float is good.  Supporting
floating-point in u-boot is more trouble than it's worth, and
-msoft-float is an easy way to make sure the code is clean.

-- 
Måns Rullgård
mans at mansr.com



More information about the U-Boot mailing list