[PATCH 0/1] Change default for cortexa* to armv7at-neon.

[PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Peter Seebach]

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

[PATCH 1/1] tune-cortexa*.inc: use armv7at by default

[Peter Seebach]

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

diff --git a/meta/conf/machine/include/tune-cortexa15.inc b/meta/conf/machine/include/tune-cortexa15.inc
index 5529777..e3cc89e 100644
--- a/meta/conf/machine/include/tune-cortexa15.inc
+++ b/meta/conf/machine/include/tune-cortexa15.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
diff --git a/meta/conf/machine/include/tune-cortexa5.inc b/meta/conf/machine/include/tune-cortexa5.inc
index 139e65c..a49b6c7 100644
--- a/meta/conf/machine/include/tune-cortexa5.inc
+++ b/meta/conf/machine/include/tune-cortexa5.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
diff --git a/meta/conf/machine/include/tune-cortexa7.inc b/meta/conf/machine/include/tune-cortexa7.inc
index 9d06910..1cdced8 100644
--- a/meta/conf/machine/include/tune-cortexa7.inc
+++ b/meta/conf/machine/include/tune-cortexa7.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
index 771537f..cd33468 100644
--- a/meta/conf/machine/include/tune-cortexa8.inc
+++ b/meta/conf/machine/include/tune-cortexa8.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc
index 700394b..3f4f8f2 100644
--- a/meta/conf/machine/include/tune-cortexa9.inc
+++ b/meta/conf/machine/include/tune-cortexa9.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7at-neon"
 
 require conf/machine/include/arm/arch-armv7a.inc
 
-- 
1.7.1

Re: [PATCH 1/1] tune-cortexa*.inc: use armv7at by default

[Khem Raj]

On 14-08-21 14:54:55, Peter Seebach wrote:
> 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.

So what do we get by making this change ?
you might be having a subset of boards that are out there
The reality is that there are boards out there which do not work well
with thumb2 therefore we cant turn it on as default instruction set.
in OE-Core we have to be conservative of support base.

> 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(-)
> 
> diff --git a/meta/conf/machine/include/tune-cortexa15.inc b/meta/conf/machine/include/tune-cortexa15.inc
> index 5529777..e3cc89e 100644
> --- a/meta/conf/machine/include/tune-cortexa15.inc
> +++ b/meta/conf/machine/include/tune-cortexa15.inc
> @@ -1,4 +1,4 @@
> -DEFAULTTUNE ?= "armv7a-neon"
> +DEFAULTTUNE ?= "armv7at-neon"
>  
>  require conf/machine/include/arm/arch-armv7a.inc
>  
> diff --git a/meta/conf/machine/include/tune-cortexa5.inc b/meta/conf/machine/include/tune-cortexa5.inc
> index 139e65c..a49b6c7 100644
> --- a/meta/conf/machine/include/tune-cortexa5.inc
> +++ b/meta/conf/machine/include/tune-cortexa5.inc
> @@ -1,4 +1,4 @@
> -DEFAULTTUNE ?= "armv7a-neon"
> +DEFAULTTUNE ?= "armv7at-neon"
>  
>  require conf/machine/include/arm/arch-armv7a.inc
>  
> diff --git a/meta/conf/machine/include/tune-cortexa7.inc b/meta/conf/machine/include/tune-cortexa7.inc
> index 9d06910..1cdced8 100644
> --- a/meta/conf/machine/include/tune-cortexa7.inc
> +++ b/meta/conf/machine/include/tune-cortexa7.inc
> @@ -1,4 +1,4 @@
> -DEFAULTTUNE ?= "armv7a-neon"
> +DEFAULTTUNE ?= "armv7at-neon"
>  
>  require conf/machine/include/arm/arch-armv7a.inc
>  
> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
> index 771537f..cd33468 100644
> --- a/meta/conf/machine/include/tune-cortexa8.inc
> +++ b/meta/conf/machine/include/tune-cortexa8.inc
> @@ -1,4 +1,4 @@
> -DEFAULTTUNE ?= "armv7a-neon"
> +DEFAULTTUNE ?= "armv7at-neon"
>  
>  require conf/machine/include/arm/arch-armv7a.inc
>  
> diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc
> index 700394b..3f4f8f2 100644
> --- a/meta/conf/machine/include/tune-cortexa9.inc
> +++ b/meta/conf/machine/include/tune-cortexa9.inc
> @@ -1,4 +1,4 @@
> -DEFAULTTUNE ?= "armv7a-neon"
> +DEFAULTTUNE ?= "armv7at-neon"
>  
>  require conf/machine/include/arm/arch-armv7a.inc
>  
> -- 
> 1.7.1
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Philip Balister]

On 08/21/2014 01:54 PM, Peter Seebach wrote:
> 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.

Can we also move to hard float abi?

Philip


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

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Peter Seebach]

On Fri, 22 Aug 2014 10:44:32 -0600
Philip Balister <philip@balister.org> 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?

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

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

On Fri, Aug 22, 2014 at 01:33:49PM -0500, Peter Seebach wrote:
> On Fri, 22 Aug 2014 10:44:32 -0600
> Philip Balister <philip@balister.org> 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?

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/openembedded-core@lists.openembedded.org/msg28907.html

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Peter Seebach]

On Fri, 22 Aug 2014 21:39:10 +0200
Martin Jansa <martin.jansa@gmail.com> 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
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]

On Fri, Aug 22, 2014 at 03:49:54PM -0500, Peter Seebach wrote:
> On Fri, 22 Aug 2014 21:39:10 +0200
> Martin Jansa <martin.jansa@gmail.com> 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.

For me it's sane default for shared binary feed and DISTRO config is the
right place to decide common denominator for your MACHINEs (if all
MACHINEs you support are cortexa9 then yes, it would be better
DEFAULTTUNE, if you enable "thumb" in default ARM_INSTRUCTION_SET, then
yes it makes sense to enable it in DEFAULTTUNE as well, but 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

and for webOS-ports we used it for a while and then reverted back to
default, because the difference between cortexa8-neon, cortexa9-neon and
armv8a-neon wasn't worth building and maintaining separate binary feed
(see links in .inc file)
https://github.com/webOS-ports/meta-webos-ports/blob/master/conf/distro/include/defaulttunes.inc

> 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
> -- 
> Listen, get this.  Nobody with a good compiler needs to be justified.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Peter Seebach]

On Fri, 22 Aug 2014 23:46:26 +0200
Martin Jansa <martin.jansa@gmail.com> 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.

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

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
> On Fri, 22 Aug 2014 23:46:26 +0200
> Martin Jansa <martin.jansa@gmail.com> 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

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)

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

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mark Hatle]

On 8/22/14, 5:26 PM, Martin Jansa wrote:
> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>> On Fri, 22 Aug 2014 23:46:26 +0200
>> Martin Jansa <martin.jansa@gmail.com> 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

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

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

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Khem Raj]

On 14-08-25 14:12:07, Mark Hatle wrote:
> On 8/22/14, 5:26 PM, Martin Jansa wrote:
> >On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
> >>On Fri, 22 Aug 2014 23:46:26 +0200
> >>Martin Jansa <martin.jansa@gmail.com> 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

yes. We should not have such case in armv7+ 

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

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

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

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

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mark Hatle]

On 8/25/14, 2:35 PM, Khem Raj wrote:
> On 14-08-25 14:12:07, Mark Hatle wrote:
>> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>>> Martin Jansa <martin.jansa@gmail.com> 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
>
> yes. We should not have such case in armv7+
>
>>
>> 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.
>
>>
>> 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.

See below, you are correct.

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

I just went and checked and I'm wrong.  I was thinking the existence of the 
'thumb' tune feature was enabling interwork.. It's actually backwards:

TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'no-thumb-interwork', ' 
-mno-thumb-interwork', ' -mthumb-interwork', d)}"
OVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'no-thumb-interwork', 
':thumb-interwork', '', d)}"

it's setting of 'no-thumb-interwork' that disables it.


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

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3407 bytes --]

On Mon, Aug 25, 2014 at 12:35:23PM -0700, Khem Raj wrote:
> On 14-08-25 14:12:07, Mark Hatle wrote:
> > On 8/22/14, 5:26 PM, Martin Jansa wrote:
> > >On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
> > >>On Fri, 22 Aug 2014 23:46:26 +0200
> > >>Martin Jansa <martin.jansa@gmail.com> 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
> 
> yes. We should not have such case in armv7+ 
> 
> > 
> > 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.
> 
> > 
> > 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.

That's what
http://patchwork.openembedded.org/patch/70985/
was trying to fix.

Now we add t (or t2) for every DEFAULTTUNE which adds thumb to
TUNE_FEATURES (for packages with both thumb and arm ISA).

> > 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.
> 
> > 
> > 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
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Philip Balister]

On 08/25/2014 03:12 PM, Mark Hatle wrote:
> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>> Martin Jansa <martin.jansa@gmail.com> 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
> 
> 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.)

The artificial benchmarks are likely anything that includes functions
returning floating point numbers.

Philip

> 
> But if changing the default to hard float were generally agreed upon
> (for architectures where VFP are available) then I wouldn't object.
> 
> --Mark
> 
>> 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)
>>
>>>> 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.
>>
>>
>>
> 

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Koen Kooi]

Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:

> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>> Martin Jansa <martin.jansa@gmail.com> 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
> 
> 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.)

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.

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mark Hatle]

On 8/28/14, 8:50 AM, Koen Kooi wrote:
>
> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:
>
>> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>>> Martin Jansa <martin.jansa@gmail.com> 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
>>
>> 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.)
>
> 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

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Koen Kooi]

Op 28 aug. 2014, om 15:57 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:

> On 8/28/14, 8:50 AM, Koen Kooi wrote:
>> 
>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:
>> 
>>> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>>>> Martin Jansa <martin.jansa@gmail.com> 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
>>> 
>>> 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.)
>> 
>> 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.

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.

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mark Hatle]

On 8/28/14, 9:08 AM, Koen Kooi wrote:
>
> Op 28 aug. 2014, om 15:57 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:
>
>> On 8/28/14, 8:50 AM, Koen Kooi wrote:
>>>
>>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:
>>>
>>>> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>>>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>>>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>>>>> Martin Jansa <martin.jansa@gmail.com> 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
>>>>
>>>> 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.)
>>>
>>> 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.
>
> 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.

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mark Hatle]

Ahh replying to myself.. see below..

On 8/28/14, 9:21 AM, Mark Hatle wrote:
> On 8/28/14, 9:08 AM, Koen Kooi wrote:
>>
>> Op 28 aug. 2014, om 15:57 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:
>>
>>> On 8/28/14, 8:50 AM, Koen Kooi wrote:
>>>>
>>>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven:
>>>>
>>>>> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>>>>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>>>>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>>>>>> Martin Jansa <martin.jansa@gmail.com> 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
>>>>>
>>>>> 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.)
>>>>
>>>> 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.
>>
>> 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.
>

Forgot.. the configuration for each follows:

TUNE_FEATURES_tune-armv7a ?= "arm armv7a vfp"
TUNE_FEATURES_tune-armv7at ?= "${TUNE_FEATURES_tune-armv7a} thumb"
TUNE_FEATURES_tune-armv7a-neon ?= "${TUNE_FEATURES_tune-armv7a} neon"
TUNE_FEATURES_tune-armv7at-neon ?= "${TUNE_FEATURES_tune-armv7at} neon"

This indicates that you can NOT enable thumb instructions (via the 
ARM_INSTRUCTION_SET) for the armv7a or armv7a-neon.  I think this is a mistake, 
and part of the reason why I'd like the -defaulttune- to change in this case. 
(Note, changing the defaulttune will not change what other machine files have 
set themselves.. it will only change the default for those who have NOT 
configured something!)

--Mark

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mike Looijmans]

On 08/28/2014 03:57 PM, Mark Hatle wrote:
> On 8/28/14, 8:50 AM, Koen Kooi wrote:
>>
>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@windriver.com>
>> het volgende geschreven:
>>
>>> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>>>> Martin Jansa <martin.jansa@gmail.com> 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
>>>
>>> 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.)
>>
>> 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.

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?


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


-- 
Mike Looijmans

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Koen Kooi]

Op 29 aug. 2014, om 08:12 heeft Mike Looijmans <mike.looijmans@topic.nl> het volgende geschreven:

> On 08/28/2014 03:57 PM, Mark Hatle wrote:
>> On 8/28/14, 8:50 AM, Koen Kooi wrote:
>>> 
>>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@windriver.com>
>>> het volgende geschreven:
>>> 
>>>> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>>>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>>>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>>>>> Martin Jansa <martin.jansa@gmail.com> 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
>>>> 
>>>> 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.)
>>> 
>>> 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.
> 
> 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?

Being link and runtime incompatible with the previous setting. It's a flag day change, something that should only be done when everyone is aware of the results. Seeing the discussion here I have no faith in that being the case.

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mark Hatle]

On 8/29/14, 1:12 AM, Mike Looijmans wrote:
> On 08/28/2014 03:57 PM, Mark Hatle wrote:
>> On 8/28/14, 8:50 AM, Koen Kooi wrote:
>>>
>>> Op 25 aug. 2014, om 21:12 heeft Mark Hatle <mark.hatle@windriver.com>
>>> het volgende geschreven:
>>>
>>>> On 8/22/14, 5:26 PM, Martin Jansa wrote:
>>>>> On Fri, Aug 22, 2014 at 05:06:26PM -0500, Peter Seebach wrote:
>>>>>> On Fri, 22 Aug 2014 23:46:26 +0200
>>>>>> Martin Jansa <martin.jansa@gmail.com> 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
>>>>
>>>> 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.)
>>>
>>> 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.
>
> 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?

Compatibility with debug tools that only know softfp.  (Note, these are pretty 
much gone now -- so I don't actually think it's that big of a deal.)

Support for commercial software..  (this is changing, but there is still a lot 
of older software out there..)

Compatibility with other ARM processors that don't have VFP.  It's still fairly 
common to build a line of devices that range from having a VFP unit to those 
that don't.  On the software side a lot of the custom (non-opensource) pieces 
are shared between devices with the only real difference being the glibc and 
some of the other routines that may heavily use math.

For -new- designs that are ARMv7a -only-.. it doesn't really matter hf or sf ABI 
-- unless there is a specific compatibility reason required (above).

My biggest complaint is developers are getting confused by both sides of the 
issue.. on one hand they're getting people telling them softfp is dead, and hf 
ABI is the only thing moving forward... and then they start a new design with a 
core that doesn't have VFP and don't know what to do.   My point is this really 
needs to work in both cases, and end users need to know what is best for their 
situation to choose properly.

--Mark

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

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Khem Raj]

On Fri, Aug 22, 2014 at 12:39 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Fri, Aug 22, 2014 at 01:33:49PM -0500, Peter Seebach wrote:
>> On Fri, 22 Aug 2014 10:44:32 -0600
>> Philip Balister <philip@balister.org> 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?
>
> 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/openembedded-core@lists.openembedded.org/msg28907.html
>

yeah I agree unless we plan to change default code generation to be thumb2
this change is causing packaging nuisance. And if you want to switch
to thumb2 default thats another pandorabox which should be fixed
before this switch can be made default.

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Mike Looijmans]

On 08/22/2014 06:44 PM, Philip Balister wrote:
...
> 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.

-- 
Mike Looijmans

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Philip Balister]

On 08/24/2014 01:56 AM, Mike Looijmans wrote:
> On 08/22/2014 06:44 PM, Philip Balister wrote:
> ...
>> 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.
> 

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

Philip

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Koen Kooi]

Op 24 aug. 2014, om 16:44 heeft Philip Balister <philip@balister.org> het volgende geschreven:

> On 08/24/2014 01:56 AM, Mike Looijmans wrote:
>> On 08/22/2014 06:44 PM, Philip Balister wrote:
>> ...
>>> 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.
>> 
> 
> The problem in the past has been binary blobs compiled for soft float.

You mean softfp, which is very different from soft float.

Re: [PATCH 0/1] Change default for cortexa* to armv7at-neon.

[Koen Kooi]

Op 21 aug. 2014, om 21:54 heeft Peter Seebach <peter.seebach@windriver.com> het volgende geschreven:

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

Thumb1 or thumb2? In the case of t1, it's useless on armv7a. The t2 case it more involved. The SoCs produced in the first ~2 years need a ton of erratum fixups enabled in the kernel, some of them mutually exclusive (e.g. enabling a work around on cortex-a8 breaks cortex-a9).

Angstrom switched to t2 builds a few months ago and a lot of devices didn't boot anymore (kernel) or segfaulted early (/sbin/init) without the appropriated kernel fixups.

So ensure everything is in place to deal with potential t2 code, all devices on my desk work with it, but that's just a tiny subset of everything out there.

regards,

Koen