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

Reply via email to