Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-07-27 at 16:25 +0100, 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, 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.
> 
> > 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.

Just to summarise where we're at with this, I thought comments had died
down from anyone likely to comment so I merged the patches since there
was a done depending upon them. Comments then picked up again.

The code is now as it stands, I'll take patches to improve/fix things as
usual...

Cheers,

Richard