On 07/27/2011 08: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, 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.
LDRD/STRD which are armv5e only are used by gcc IIRC
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.
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
