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

[Mark Hatle]

On 8/25/14, 2:35 PM, Khem Raj wrote:
> On 14-08-25 14:12:07, Mark Hatle wrote:
>> 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
>
> yes. We should not have such case in armv7+
>
>>
>> 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.
>
> if thats what we do then we are wrong. Since thumb interwork is
> mandatory when we claim EABI compatibility and I think we have stopped
> supporting Old ABI hence EABI is default which means interworking is
> inherent.
>
>>
>> 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...)
>
> FWIW adding 't' in there should just be done when the resulting binary
> is compiled using thumb ISA, using 't' to qualify interworking
> capablility is not required.

See below, you are correct.

>>
>> 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.
>
> I dont believe thats the case we simply should not be able to disable
> interworking.

I just went and checked and I'm wrong.  I was thinking the existence of the 
'thumb' tune feature was enabling interwork.. It's actually backwards:

TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'no-thumb-interwork', ' 
-mno-thumb-interwork', ' -mthumb-interwork', d)}"
OVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'no-thumb-interwork', 
':thumb-interwork', '', d)}"

it's setting of 'no-thumb-interwork' that disables it.


>>
>> 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.)
>>
>> But if changing the default to hard float were generally agreed upon (for
>> architectures where VFP are available) then I wouldn't object.
>>
>
> I would leave that choice to distributions for now
>