Change default for cortexa* to armv7at-neon.

Every cortexa* chip I've encountered so far has been capable of executing Thumb code, so it probably makes more sense to use armv7at-neon instead of armv7a-neon as the DEFAULTTUNE. Choice of code generation is controlled separately, by ARM_INSTRUCTION_SET.

Most packages tend to perform at comparably with thumb because smaller code footprint means better cache efficiency.

---
 meta/conf/machine/include/tune-cortexa15.inc |    2 +-
 meta/conf/machine/include/tune-cortexa5.inc  |    2 +-
 meta/conf/machine/include/tune-cortexa7.inc  |    2 +-
 meta/conf/machine/include/tune-cortexa8.inc  |    2 +-
 meta/conf/machine/include/tune-cortexa9.inc  |    2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

meta/conf/machine/include/tune-cortexa15.inc +1 -1

index 5529777..e3cc89e 100644
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 

meta/conf/machine/include/tune-cortexa5.inc +1 -1

index 139e65c..a49b6c7 100644
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 

meta/conf/machine/include/tune-cortexa7.inc +1 -1

index 9d06910..1cdced8 100644
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 

meta/conf/machine/include/tune-cortexa8.inc +1 -1

index 771537f..cd33468 100644
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 

meta/conf/machine/include/tune-cortexa9.inc +1 -1

index 700394b..3f4f8f2 100644
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 

Signature · 7 lines

1.7.1

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

The various cortex chips generally support thumb code, so the armv7at tunings are a better default for them than the plain armv7a tunings. The armv7at tuning allows generation of both arm and thumb code, while armv7a only allows arm code, which is typically significantly bigger. (It may be faster in some cases, but the tradeoffs aren't totally obvious, because smaller code fits in caches better.) Since they all had armv7a-neon as default, change them to armv7at-neon.

The following changes since commit 47d1fc9f5c38f3d092937c47bd4c2f45adaa7fe6:

qemu: fix Darwin cross-compilation (2014-08-18 20:43:24 +0100)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib seebs/armv7at
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/armv7at

Peter Seebach (1):
tune-cortexa*.inc: use armv7at by default

 meta/conf/machine/include/tune-cortexa15.inc |    2 +-
 meta/conf/machine/include/tune-cortexa5.inc  |    2 +-
 meta/conf/machine/include/tune-cortexa7.inc  |    2 +-
 meta/conf/machine/include/tune-cortexa8.inc  |    2 +-
 meta/conf/machine/include/tune-cortexa9.inc  |    2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

Can we also move to hard float abi?

Quoted 1 line · On Fri, 22 Aug 2014 10:44:32 -0600 Philip Balister <[email protected]> wrote:

Can we also move to hard float abi?

I'd rather not, just because the reason I care about this at all is that our prebuilt toolchain has a set of binaries for armv7at-neon, but not for hard float ABI.

I am reminded, though, of a question I had about all the cortex tunings:

Why do they set DEFAULTTUNE to a tuning that isn't one of the ones using the new features they define?

Even enabling thumb seems wrong, because ARM_INSTRUCTION_SET is arm by default, so this change is only renaming the feed, but still building the same binaries (unless distro sets ARM_INSTRUCTION_SET).

Quoted 3 lines · On Fri, 22 Aug 2014 21:39:10 +0200 Martin Jansa <[email protected]> wrote:

Even enabling thumb seems wrong, because ARM_INSTRUCTION_SET is arm by default, so this change is only renaming the feed, but still building the same binaries (unless distro sets ARM_INSTRUCTION_SET).

I think that's okay, because the point is to correctly indicate that the CPU can run thumb binaries if someone had a reason to make them.

I mean, strictly speaking, I don't even *know of* an actual chip for which armv7a-neon is a correct descriptor. Because "armv7a-neon" is a chip which *cannot* run thumb binaries. Does anyone actually make a neon armv7a which can't run thumb binaries?

And yeah, the RFC and ensuing discussion gets to some sort of underlying questions about what the purpose of DEFAULTTUNE is. I am inclined to think that the DEFAULTTUNE for a given tune-foo should be either the baseline of that chipset or a somewhat optimized tune for it.

I note that tune-core2 and tune-corei7 both set tunes (core2-32, corei7-64) which include target-specific optimizations; this would be comparable to using cortexa9t-neon as the default tune for tune-cortexa9.inc.

I don't think the current state of tunings reflects a completely consistent view of what DEFAULTTUNE means in a tuning file.

-s

Signature · 1 line

Listen, get this.  Nobody with a good compiler needs to be justified.

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Every distro can use something more "optimized" DEFAULTTUNEs for each MACHINE they use, I do it for SHR:
https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr-distro/conf/distro/include/defaulttunes.inc

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

Quoted 3 lines

Every distro can use something more "optimized" DEFAULTTUNEs for each MACHINE they use, I do it for SHR:
https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr-distro/conf/distro/include/defaulttunes.inc

Huh, that's an interesting point. I'll wave this at people and see what they think of it.

-s

Signature · 1 line

Listen, get this.  Nobody with a good compiler needs to be justified.

Quoted 8 lines · Peter Seebach

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The problem is that "t" in DEFAULTUNE always adds "t2" to TUNE_PKGARCH no matter if you've built the package with -marm or -mthumb. So as long as ARM_INSTRUCTION_SET is "arm" by default, we should use the same default for DEFAULTTUNE - I wouldn't mind changing ARM_INSTRUCTION_SET at least more people will be hit by those ICEs I've reported earlier (with patch forcing ARM_INSTRUCTION_SET to "arm" for gdb and icu "gdb: force arm mode" http://patchwork.openembedded.org/patch/75703/
"icu: force arm mode" http://patchwork.openembedded.org/patch/75817/

It would be interesting to try
http://patchwork.openembedded.org/patch/70985/
with latest master to see if it can work correctly now, then I wouldn't be so opposed to "enabling" thumb in DEFAULTTUNE (even without ARM_INSTRUCTION_SET change)

Quoted 10 lines

Quoted 3 lines

Every distro can use something more "optimized" DEFAULTTUNEs for each MACHINE they use, I do it for SHR:
https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr-distro/conf/distro/include/defaulttunes.inc

Huh, that's an interesting point. I'll wave this at people and see what they think of it.

-s
--
Listen, get this. Nobody with a good compiler needs to be justified.

Quoted 9 lines · Martin Jansa

Quoted 8 lines · Peter Seebach

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

But if changing the default to hard float were generally agreed upon (for architectures where VFP are available) then I wouldn't object.

Quoted 10 lines · Mark Hatle

Quoted 9 lines · Martin Jansa

Quoted 8 lines · Peter Seebach

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

yes. We should not have such case in armv7+

Quoted 5 lines

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

if thats what we do then we are wrong. Since thumb interwork is mandatory when we claim EABI compatibility and I think we have stopped supporting Old ABI hence EABI is default which means interworking is inherent.

Quoted 1 line

Quoted 3 lines

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

FWIW adding 't' in there should just be done when the resulting binary is compiled using thumb ISA, using 't' to qualify interworking capablility is not required.

Quoted 8 lines

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

I dont believe thats the case we simply should not be able to disable interworking.

Quoted 10 lines

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

But if changing the default to hard float were generally agreed upon (for architectures where VFP are available) then I wouldn't object.

I would leave that choice to distributions for now

Quoted 10 lines · Mark Hatle

Quoted 9 lines · Martin Jansa

Quoted 8 lines · Peter Seebach

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

yes. We should not have such case in armv7+

Quoted 5 lines

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

if thats what we do then we are wrong. Since thumb interwork is mandatory when we claim EABI compatibility and I think we have stopped supporting Old ABI hence EABI is default which means interworking is inherent.

Quoted 1 line

Quoted 3 lines

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

FWIW adding 't' in there should just be done when the resulting binary is compiled using thumb ISA, using 't' to qualify interworking capablility is not required.

Quoted 7 lines

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

I dont believe thats the case we simply should not be able to disable interworking.

Quoted 10 lines

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

But if changing the default to hard float were generally agreed upon (for architectures where VFP are available) then I wouldn't object.

I would leave that choice to distributions for now

Signature · 4 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 18 lines · Martin Jansa

Quoted 16 lines · Peter Seebach

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense
to use a tuning that specifically states that it can't run thumb code for
processors which can. Although... May not be an important distinction, really,
as you note.

Quoted 2 lines

Quoted 2 lines

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

But if changing the default to hard float were generally agreed upon (for architectures where VFP are available) then I wouldn't object.

--Mark

Quoted 30 lines

The problem is that "t" in DEFAULTUNE always adds "t2" to TUNE_PKGARCH no matter if you've built the package with -marm or -mthumb. So as long as ARM_INSTRUCTION_SET is "arm" by default, we should use the same default for DEFAULTTUNE - I wouldn't mind changing ARM_INSTRUCTION_SET at least more people will be hit by those ICEs I've reported earlier (with patch forcing ARM_INSTRUCTION_SET to "arm" for gdb and icu "gdb: force arm mode" http://patchwork.openembedded.org/patch/75703/
"icu: force arm mode" http://patchwork.openembedded.org/patch/75817/

It would be interesting to try
http://patchwork.openembedded.org/patch/70985/
with latest master to see if it can work correctly now, then I wouldn't be so opposed to "enabling" thumb in DEFAULTTUNE (even without ARM_INSTRUCTION_SET change)

Quoted 12 lines

Quoted 4 lines

Every distro can use something more "optimized" DEFAULTTUNEs for each MACHINE they use, I do it for SHR:
https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr-distro/conf/distro/include/defaulttunes.inc

Huh, that's an interesting point. I'll wave this at people and see what they
think of it.

-s

Signature · 1 line

Listen, get this.  Nobody with a good compiler needs to be justified.

Quoted 9 lines · Peter Seebach

Quoted 8 lines

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

Op 25 aug. 2014, om 21:12 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 25 lines · Martin Jansa

Quoted 9 lines · Peter Seebach

Quoted 8 lines

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

Quoted 5 lines

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray.

Quoted 34 lines

Op 25 aug. 2014, om 21:12 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 30 lines · Martin Jansa

Quoted 9 lines · Peter Seebach

Quoted 8 lines

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

Quoted 2 lines

Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray.

Exactly. Which is why I haven't recommended to my customers that they -need- the HF ABI, like others in the ARM world seem to be insisting.

If you have a LOT of functions that pass floats, or you do it often enough to see the behavior -- I can see how it would be useful. But this is fairly artificial in most of the embedded workloads I'm familiar with.

So I'd still say I'd like to change the cortexa* DEFAULTTUNES to reference armv7at or armv7at-neon (continue the softfp ABI for the time being). I'd be fine with the at-neon version, as I think all of the commodity armv7a's have neon.

Op 28 aug. 2014, om 15:57 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 38 lines · Koen Kooi

Quoted 36 lines

Op 25 aug. 2014, om 21:12 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 23 lines · Martin Jansa

Quoted 9 lines · Peter Seebach

Quoted 8 lines

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

Quoted 7 lines

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray.

Quoted 5 lines

Exactly. Which is why I haven't recommended to my customers that they -need- the HF ABI, like others in the ARM world seem to be insisting.

If you have a LOT of functions that pass floats, or you do it often enough to see the behavior -- I can see how it would be useful. But this is fairly artificial in most of the embedded workloads I'm familiar with.

So I'd still say I'd like to change the cortexa* DEFAULTTUNES to reference armv7at or armv7at-neon (continue the softfp ABI for the time being). I'd be fine with the at-neon version, as I think all of the commodity armv7a's have neon.

Thumb1 support has never been stable, so I don't see what it will buy us. It just seems a way to piss of DISTROs without any benefits.

Quoted 41 lines · Koen Kooi

Op 28 aug. 2014, om 15:57 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 38 lines · Koen Kooi

Quoted 36 lines

Op 25 aug. 2014, om 21:12 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 23 lines · Martin Jansa

Quoted 9 lines · Peter Seebach

Quoted 8 lines

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

Quoted 8 lines

Quoted 8 lines

I think the distinction is that if you use armv7at-neon, you *can* build specific packages with thumb. Mostly, I guess, I don't think it makes sense to use a tuning that specifically states that it can't run thumb code for processors which can. Although... May not be an important distinction, really, as you note.

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

Quoted 7 lines

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray.

Quoted 8 lines

Quoted 5 lines

Exactly. Which is why I haven't recommended to my customers that they -need- the HF ABI, like others in the ARM world seem to be insisting.

If you have a LOT of functions that pass floats, or you do it often enough to see the behavior -- I can see how it would be useful. But this is fairly artificial in most of the embedded workloads I'm familiar with.

So I'd still say I'd like to change the cortexa* DEFAULTTUNES to reference armv7at or armv7at-neon (continue the softfp ABI for the time being). I'd be fine with the at-neon version, as I think all of the commodity armv7a's have neon.

Thumb1 support has never been stable, so I don't see what it will buy us. It just seems a way to piss of DISTROs without any benefits.

't' in the tune name indicates thumb of the appropriate version for the part.

meta/conf/machine/include/arm/feature-arm-thumb.inc:

TUNEVALID[thumb] = "Use thumb instructions instead of ARM" ARM_THUMB_OPT = "${@['arm', 'thumb'][d.getVar('ARM_INSTRUCTION_SET', True) == 'thumb']}"

ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4',  't',  '', d)}"
ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5',  't',  '', d)}"
ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6',  't',  '', d)}"

ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 't2', '', d)}" ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7r', 't2', '', d)}" ARM_THUMB_SUFFIX .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7m', 't2', '', d)}"

There is a table that actually switches on the right suffix for the part in question. The -name- ending in a 't' simply means thumb may be enabled.

Thumb instructions are enabled either within the recipe itself or via the "ARM_INSTRUCTION_SET" function.

Quoted 52 lines · Koen Kooi

Op 25 aug. 2014, om 21:12 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 42 lines · Martin Jansa

Quoted 19 lines · Peter Seebach

Quoted 17 lines

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

I think the distinction is that if you use armv7at-neon, you *can* build
specific packages with thumb. Mostly, I guess, I don't think it makes sense
to use a tuning that specifically states that it can't run thumb code for
processors which can. Although... May not be an important distinction, really,
as you note.

Quoted 2 lines

Quoted 2 lines

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

Quoted 5 lines

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

Quoted 5 lines

Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray.

Exactly. Which is why I haven't recommended to my customers that they -need- the HF ABI, like others in the ARM world seem to be insisting.

If you have a LOT of functions that pass floats, or you do it often enough to see the behavior -- I can see how it would be useful. But this is fairly artificial in most of the embedded workloads I'm familiar with.

So I'd still say I'd like to change the cortexa* DEFAULTTUNES to reference armv7at or armv7at-neon (continue the softfp ABI for the time being). I'd be fine with the at-neon version, as I think all of the commodity armv7a's have neon.

--Mark

Quoted 59 lines · Koen Kooi

Quoted 52 lines

Op 25 aug. 2014, om 21:12 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 42 lines · Martin Jansa

Quoted 19 lines · Peter Seebach

Quoted 17 lines

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

I think the distinction is that if you use armv7at-neon, you *can* build
specific packages with thumb. Mostly, I guess, I don't think it makes sense
to use a tuning that specifically states that it can't run thumb code for
processors which can. Although... May not be an important distinction, really,
as you note.

Quoted 2 lines

Quoted 2 lines

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

Quoted 5 lines

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

Quoted 5 lines

Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray.

Quoted 7 lines

Exactly. Which is why I haven't recommended to my customers that they -need- the HF ABI, like others in the ARM world seem to be insisting.

If you have a LOT of functions that pass floats, or you do it often enough to see the behavior -- I can see how it would be useful. But this is fairly artificial in most of the embedded workloads I'm familiar with.

That's because we all learned to work around the softfp. I got bitten by it once, so I also learned to avoid passing floats around across library boundaries as much as possible. GCC is smart enough to use hardfloat on internal methods, but its hands are tied when interfacing with externals.

There are other, more subtle effects to using hardfloat. For one thing, it increases the number of registers available to pass parameters around.

I can see the case for not really needing hardfloat. But I fail to see the advantage of strictly adhering to softfp just "because we used to". What's the big disadvantage in moving to hardfloat?

Quoted 59 lines · Mark Hatle

Quoted 52 lines · Koen Kooi

Op 25 aug. 2014, om 21:12 heeft Mark Hatle <[email protected]> het volgende geschreven:

Quoted 42 lines · Martin Jansa

Quoted 19 lines · Peter Seebach

Quoted 17 lines

Quoted 4 lines · On Fri, 22 Aug 2014 23:46:26 +0200 Martin Jansa <[email protected]> wrote:

changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while still building with -marm doesn't make much sense to me and is only confusing.

I think the distinction is that if you use armv7at-neon, you *can* build
specific packages with thumb. Mostly, I guess, I don't think it makes sense
to use a tuning that specifically states that it can't run thumb code for
processors which can. Although... May not be an important distinction, really,
as you note.

Quoted 2 lines

Quoted 2 lines

I don't think it makes sense to use a tuning that specifically states that it can't run thumb code

The defaulttune is supposed to supply what the processor and ABI are capable of.

So in the case of armv7a, it's saying no thumb support at all, this included thumb interwork.

armv7at says that the processor supports thumb, and interwork -should- be enabled. (It can of course be manually disabled, but that's another issue to be dealt with...)

armv7at doesn't say it actually includes thumb combines binaries. (I argued originally it should, but was overruled for a variety of reasons... not the least of which is the interwork enabled, and multilib issues with 'same abi' configurations.)

So I agree the default should be armv7at or armv7at-neon, unless there is a compelling reason to leave it as a default with interwork disabled.

Quoted 5 lines

As for the hard float question. I'm torn on this.. for compatibility a lot of the industry is still soft-float based, and frankly I've not exactly encouraged it with my customers.. (I'm not seeing general performance improvements, only improvements in select artificial benchmarks, or specific pieces of code.)

Quoted 5 lines

Again, softfloat != softfp. The current OE default of softfp *does* use the VFP, it just passed the floats in the integer registers. Which is why you will see no difference with hardfloat except for benchmarks and povray.

Quoted 7 lines

Exactly. Which is why I haven't recommended to my customers that they -need- the HF ABI, like others in the ARM world seem to be insisting.

If you have a LOT of functions that pass floats, or you do it often enough to see the behavior -- I can see how it would be useful. But this is fairly artificial in most of the embedded workloads I'm familiar with.

That's because we all learned to work around the softfp. I got bitten by it once, so I also learned to avoid passing floats around across library boundaries as much as possible. GCC is smart enough to use hardfloat on internal methods, but its hands are tied when interfacing with externals.

There are other, more subtle effects to using hardfloat. For one thing, it increases the number of registers available to pass parameters around.

I can see the case for not really needing hardfloat. But I fail to see the advantage of strictly adhering to softfp just "because we used to". What's the big disadvantage in moving to hardfloat?

Quoted 8 lines

So I'd still say I'd like to change the cortexa* DEFAULTTUNES to reference armv7at or armv7at-neon (continue the softfp ABI for the time being). I'd be fine with the at-neon version, as I think all of the commodity armv7a's have neon.

--Mark

Quoted 5 lines · Peter Seebach

Quoted 1 line · On Fri, 22 Aug 2014 10:44:32 -0600 Philip Balister <[email protected]> wrote:

Can we also move to hard float abi?

Quoted 8 lines

I'd rather not, just because the reason I care about this at all is that our prebuilt toolchain has a set of binaries for armv7at-neon, but not for hard float ABI.

I am reminded, though, of a question I had about all the cortex tunings:

Why do they set DEFAULTTUNE to a tuning that isn't one of the ones using the new features they define?

Because it's always compromise between optimizing for given device and sharing the same DEFAULTTUNE (and its binary feed) for many MACHINEs supported by DISTRO.

Even enabling thumb seems wrong, because ARM_INSTRUCTION_SET is arm by default, so this change is only renaming the feed, but still building the same binaries (unless distro sets ARM_INSTRUCTION_SET).

Please check this old RFC for more details:
https://www.mail-archive.com/[email protected]/msg28907.html

Can we also move to hard float abi?

On 08/22/2014 06:44 PM, Philip Balister wrote:
...

Quoted 2 lines

Can we also move to hard float abi?

+1 to that.

Especially since "neon" implies "float" support on the Cortex.

We moved to hard float on the MIPS (mostly broadcom) many years ago. I always wondered why the ARM never made that move.

Quoted 7 lines · Philip Balister

...

Quoted 2 lines

Can we also move to hard float abi?

+1 to that.

Quoted 5 lines

Especially since "neon" implies "float" support on the Cortex.

We moved to hard float on the MIPS (mostly broadcom) many years ago. I always wondered why the ARM never made that move.

The problem in the past has been binary blobs compiled for soft float.

The various cortex chips generally support thumb code, so the armv7at tunings are a better default for them than the plain armv7a tunings.