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.
So I'd still say I'd like to change the cortexa* DEFAULTTUNES to reference
armv7at or armv7at-neon (continue the softfp ABI for the time being). I'd be
fine with the at-neon version, as I think all of the commodity armv7a's have neon.
--Mark
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
