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

[Mark Hatle]

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

--Mark

> p.
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core