Op 29 aug. 2014, om 08:12 heeft Mike Looijmans <mike.looijm...@topic.nl> het volgende geschreven:
> On 08/28/2014 03:57 PM, Mark Hatle wrote: >> On 8/28/14, 8:50 AM, Koen Kooi wrote: >>> >>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.ha...@windriver.com> >>> het volgende geschreven: >>> >>>> On 8/22/14, 5:26 PM, Martin Jansa wrote: >>>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote: >>>>>> On Fri, 22 Aug 2014 23:46:26 +0200 >>>>>> Martin Jansa <martin.ja...@gmail.com> wrote: >>>>>> >>>>>>> changing >>>>>>> default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while >>>>>>> still building with -marm doesn't make much sense to me and is only >>>>>>> confusing. >>>>>> >>>>>> I think the distinction is that if you use armv7at-neon, you *can* >>>>>> build >>>>>> specific packages with thumb. Mostly, I guess, I don't think it >>>>>> makes sense >>>>>> to use a tuning that specifically states that it can't run thumb >>>>>> code for >>>>>> processors which can. Although... May not be an important >>>>>> distinction, really, >>>>>> as you note. >>>>> >>>>>> I don't think it makes sense to use a tuning that specifically states >>>>>> that it can't run thumb code >>>> >>>> The defaulttune is supposed to supply what the processor and ABI are >>>> capable of. >>>> >>>> So in the case of armv7a, it's saying no thumb support at all, this >>>> included thumb interwork. >>>> >>>> armv7at says that the processor supports thumb, and interwork >>>> -should- be enabled. (It can of course be manually disabled, but >>>> that's another issue to be dealt with...) >>>> >>>> armv7at doesn't say it actually includes thumb combines binaries. (I >>>> argued originally it should, but was overruled for a variety of >>>> reasons... not the least of which is the interwork enabled, and >>>> multilib issues with 'same abi' configurations.) >>>> >>>> So I agree the default should be armv7at or armv7at-neon, unless >>>> there is a compelling reason to leave it as a default with interwork >>>> disabled. >>>> >>>> As for the hard float question. I'm torn on this.. for compatibility >>>> a lot of the industry is still soft-float based, and frankly I've not >>>> exactly encouraged it with my customers.. (I'm not seeing general >>>> performance improvements, only improvements in select artificial >>>> benchmarks, or specific pieces of code.) >>> >>> Again, softfloat != softfp. The current OE default of softfp *does* >>> use the VFP, it just passed the floats in the integer registers. Which >>> is why you will see no difference with hardfloat except for benchmarks >>> and povray. >>> >> >> Exactly. Which is why I haven't recommended to my customers that they >> -need- the HF ABI, like others in the ARM world seem to be insisting. >> >> If you have a LOT of functions that pass floats, or you do it often >> enough to see the behavior -- I can see how it would be useful. But >> this is fairly artificial in most of the embedded workloads I'm familiar >> with. > > That's because we all learned to work around the softfp. I got bitten by it > once, so I also learned to avoid passing floats around across library > boundaries as much as possible. GCC is smart enough to use hardfloat on > internal methods, but its hands are tied when interfacing with externals. > > There are other, more subtle effects to using hardfloat. For one thing, it > increases the number of registers available to pass parameters around. > > I can see the case for not really needing hardfloat. But I fail to see the > advantage of strictly adhering to softfp just "because we used to". What's > the big disadvantage in moving to hardfloat? Being link and runtime incompatible with the previous setting. It's a flag day change, something that should only be done when everyone is aware of the results. Seeing the discussion here I have no faith in that being the case. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
