[OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

[Khem Raj]

On 07/27/2011 10:19 AM, Mark Hatle wrote:
> On 7/27/11 10:25 AM, Phil Blundell wrote:
>> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>>> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
>>> means I was thumb instructions.
>>>
>>> So armv5 and armv5t are distinct in the contents of the tunings.
>>
>> Ah, I see.  Does that go for v4t too?  I can imagine cases where you
>> would want to say "select the v4T ISA but generate ARM code not Thumb".
>
> Yes, for all of them, the TUNENAME selects the features that you want to use to
> compile, and suggests the other information like compatible architectures.
>
> In the case where you want to build primarily one, and optionally the other the
> tunename makes it easy..
>
> Say you want all of your system thumb, except for a few specific programs..
>
> TUNENAME = "armv4t"
>
> TUNENAME_pn-mysql = "armv4"
>
> In the opposite case, where you want everything ARM, except for a few thumb:
>
> TUNENAME = "armv7"
> TUNENAME_pn-bash = "armv7t"
>
> PACKAGE_EXTRA_ARCHS_tune-armv7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7t}
>
> Second line ensures that the base armv7 tune inherits the "more complete" set of
> compatible machines.
>
> (Note, in most cases I would expect a machine/BSP configuration to do most of
> this inheriting... or if someone was being tricky they can do it manually.)
>>> Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
>>> the "dsp" capabilities actually change any of the code or support generated.  If
>>> not then we can ignore it.
>>
>> Yes.  PLD, for example, is only available in ARMv5E (not ARMv5) and this
>> will affect any code which uses __builtin_prefetch().  I don't think GCC
>> will ever open-code the saturating arithmetic instructions, but it does
>> expose the v5/v5e distinction through preprocessor macros and source
>> code might use that to select asm() statements which use those opcodes.
>
> So then the question is.. with OE-core and core based distros.. are there enough
> armv5 (w/ or w/o e) left to justify having both?  If not.. then we select the
> one with the 'e' since it's more common.
>
>>> For armv5 this gives us:
>>>
>>> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
>>> EABI...
>>
>> Does anybody really want the hardfloat abi on armv5?  I guess it doesn't
>> hurt all that much to offer it, but anything that makes that monstrous
>> set of .inc files bigger seems like a bad thing.
>
> I was surprised anyone wanted the hardfloat ABI at all.. :P ...but anyway... if
> it'll work on armv5 (and the previous question about is armv5 relevant answered)
> we can choose it or not..  It was there to be complete in the original
> version...  (also armv5 w/ VFP is the lowest compatible machine for a HF
> implementation.)
>

hardfloat ABI may not work with VFP implementation which is on the armv5 
cores it was designed around vfpv3
> --Mark
>
>> p.
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core