[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