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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
