From: Phil Blundell <philb@gnu.org>
To: openembedded-core@lists.openembedded.org
Subject: Re: qemuarm: should it really have TUNE_ARCH armv5te?
Date: Thu, 13 Sep 2012 18:02:13 +0100 [thread overview]
Message-ID: <1347555734.1786.19.camel@phil-desktop> (raw)
In-Reply-To: <50520E2E.1040804@windriver.com>
On Thu, 2012-09-13 at 11:47 -0500, Mark Hatle wrote:
> ARM seems to be the one exception, where you have three levels.. ABI
> (EABI/hf-EABI), processor family (armv4, armv5, armv7, cortext....), and then
> CPU optimization. This seems to cause additional confusion, as the CPU
> optimizations are not being captured in the current package ARCH, which makes it
> difficult to optimize on a feed.
I guess that by "processor family" you mean ISA. (I'm not aware of an
ARM ISA variant named "cortext", though I haven't really been keeping up
with the latest developments there so I could imagine that one might
exist.)
Anyway, the basic three-way scenario (ISA, ABI, optimisation) that you
describe above isn't in any sense unique to ARM; the concept of
per-cpu-model optimisation/tuning applies equally to other architectures
(x86 for example) as well. It's probably less of an issue for MIPS but
I suspect that's more a reflection of gcc's weaker optimisation
capabilities on that architecture rather than a homogeous CPU
population. I don't know PowerPC well enough to make any comment about
that.
There's no particular reason that the per-cpu tuning couldn't be
captured in PACKAGE_ARCH if one wanted to do it. But the decision about
how to structure a binary feed is clearly one for the DISTRO and the
question of how to map that into PACKAGE_ARCH is, equally clearly, one
that the distro ought to be solving. Since oe-core itself doesn't build
any feeds, I don't think there's any reason for it to make heroic
efforts to sort out the package architectures that would go into them.
p.
prev parent reply other threads:[~2012-09-13 17:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 13:01 qemuarm: should it really have TUNE_ARCH armv5te? Martin Jansa
2012-09-11 13:48 ` Martin Jansa
2012-09-11 15:51 ` ARM-tuning -- was " Mark Hatle
2012-09-11 15:59 ` Martin Jansa
2012-09-11 16:09 ` Mark Hatle
2012-09-11 16:22 ` Martin Jansa
2012-09-11 16:13 ` Koen Kooi
2012-09-11 18:40 ` Khem Raj
2012-09-11 18:53 ` Phil Blundell
2012-09-11 19:58 ` Khem Raj
2012-09-11 16:46 ` Phil Blundell
2012-09-11 16:53 ` Martin Jansa
2012-09-11 17:14 ` Phil Blundell
2012-09-11 17:21 ` Martin Jansa
2012-09-11 17:35 ` Martin Jansa
2012-09-11 17:37 ` Phil Blundell
2012-09-11 17:43 ` Martin Jansa
2012-09-11 18:00 ` Mark Hatle
2012-09-12 14:33 ` Richard Purdie
2012-09-13 6:20 ` Martin Jansa
2012-09-13 10:42 ` Richard Purdie
2012-09-13 12:14 ` Martin Jansa
2012-09-13 12:58 ` Richard Purdie
2012-09-15 7:01 ` Martin Jansa
2012-09-21 15:52 ` Martin Jansa
2012-09-22 11:48 ` Richard Purdie
2012-09-13 16:47 ` Mark Hatle
2012-09-13 17:02 ` Phil Blundell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1347555734.1786.19.camel@phil-desktop \
--to=philb@gnu.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.