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

[Mark Hatle <mark.hatle@windriver.com>]

On 8/28/14, 9:08 AM, Koen Kooi wrote:
>
> Op 28 aug. 2014, om 15:57 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:
>
>> On 8/28/14, 8:50 AM, Koen Kooi wrote:
>>>
>>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@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@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.
>
> Thumb1 support has never been stable, so I don't see what it will buy us. It just seems a way to piss of DISTROs without any benefits.
>

't' in the tune name indicates thumb of the appropriate version for the part.

meta/conf/machine/include/arm/feature-arm-thumb.inc:

TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
ARM_THUMB_OPT = "${@['arm', 'thumb'][d.getVar('ARM_INSTRUCTION_SET', True) == 
'thumb']}"
ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4',  't',  '', d)}"
ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5',  't',  '', d)}"
ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6',  't',  '', d)}"
ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 't2', '', d)}"
ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7r', 't2', '', d)}"
ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7m', 't2', '', d)}"

There is a table that actually switches on the right suffix for the part in 
question.  The -name- ending in a 't' simply means thumb may be enabled.

Thumb instructions are enabled either within the recipe itself or via the 
"ARM_INSTRUCTION_SET" function.