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. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core