[OE-core] [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mark Hatle]

On 8/29/14, 1:12 AM, Mike Looijmans wrote:
> 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.hatle at 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.jansa at 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?

Compatibility with debug tools that only know softfp.  (Note, these are pretty 
much gone now -- so I don't actually think it's that big of a deal.)

Support for commercial software..  (this is changing, but there is still a lot 
of older software out there..)

Compatibility with other ARM processors that don't have VFP.  It's still fairly 
common to build a line of devices that range from having a VFP unit to those 
that don't.  On the software side a lot of the custom (non-opensource) pieces 
are shared between devices with the only real difference being the glibc and 
some of the other routines that may heavily use math.

For -new- designs that are ARMv7a -only-.. it doesn't really matter hf or sf ABI 
-- unless there is a specific compatibility reason required (above).

My biggest complaint is developers are getting confused by both sides of the 
issue.. on one hand they're getting people telling them softfp is dead, and hf 
ABI is the only thing moving forward... and then they start a new design with a 
core that doesn't have VFP and don't know what to do.   My point is this really 
needs to work in both cases, and end users need to know what is best for their 
situation to choose properly.

--Mark

>
>>
>> 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
>
>