Albert ARIBAUD <albert.arib...@free.fr> writes: > Le 19/02/2011 15:34, Måns Rullgård a écrit : >> Albert ARIBAUD<albert.arib...@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 m...@mansr.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
