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. 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. And it is not as if the C code used floats. Besides, so far I have seen no complaint that -msoft-float disabling -mfpu=neon causes any problem with U-Boot, so I suspect no board requires it now. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot