public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Phil Blundell <pb@pbcl.net>
To: Andre McCurdy <armccurdy@gmail.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCHv2][RFC] arch-armv7ve.inc: respect armv7a override as well
Date: Fri, 08 Jan 2016 20:44:43 +0000	[thread overview]
Message-ID: <1452285883.1933.31.camel@pbcl.net> (raw)
In-Reply-To: <CAJ86T=VQdAB9dRRb4c_XmFOO+BxH13ar=-Fi209Z59Ry6zVy1w@mail.gmail.com>

On Fri, 2016-01-08 at 10:24 -0800, Andre McCurdy wrote:
> On Fri, Jan 8, 2016 at 9:00 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Fri, Jan 08, 2016 at 08:24:36AM -0800, Andre McCurdy wrote:
> >> If it's a long term solution then how will armv7m and armv7r be
> >> handled? They are likely to need to duplicate a lot of the current
> >> armv7a over-rides too.
> >
> > armv7a and armv7ve are much closer than armv7a and armv7m or armv7r as
> > Khem said in earlier discussion.
> 
> I'm not sure what the definition of "close" is here. An armv7a CPU can
> not run armv7ve binaries.
> 
> Saying armv7a and armv7ve are close is like saying armv4 and armv5 are
> close. True in some respects, but they don't define each other's
> over-rides.

Yeah, there clearly is some difference in "closeness".

armv4 and armv5 are at least moderately close, in the sense that an
armv5 processor can run almost all (though not absolutely all) armv4
binaries.  There are some significant differences in code generation
and, in particular, ARMv4 is not supported by the EABI (i.e. binary
libraries compiled with -march=armv4 are not EABI compliant).

armv7a and armv7ve are close to each other in the sense that an armv7ve
processor can run any armv7a binary (i.e. the architecture with
virtualisation extensions is a superset of the one without), and there
are only fairly minor differences in code generation between the two.

armv7a and armv7r are, as far as application code needs to be concerned,
more or less equivalent.  Clearly ARMv7-R cores don't have MMUs, but
this ought to manifest itself in a different TARGET_OS setting and there
should be no particular need for overrides to distinguish armv7r
specifically.

armv7m and armv7a/r are a bit more complicated because, in general, you
can't run an armv7a/r binary on an armv7m processor (which doesn't have
32 bit instructions) and you can't run an armv7m binary on an armv7a
processor (which may not have the divide instruction).  It might be true
to say that armv7ve processors can always run binaries built for armv7m;
I'm not sure.  But whether there are any situations where overrides need
to care is unclear.

But overall I remain fairly convinced that the direction of travel ought
to be towards having fewer overrides, and the ones that we do have being
more semantically meaningful.

p.




  reply	other threads:[~2016-01-08 20:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 12:36 [PATCH][RFC] arch-armv7ve.inc: respcet armv7a override as well Martin Jansa
2016-01-08 12:44 ` [PATCHv2][RFC] arch-armv7ve.inc: respect " Martin Jansa
2016-01-08 16:24   ` Andre McCurdy
2016-01-08 17:00     ` Martin Jansa
2016-01-08 18:24       ` Andre McCurdy
2016-01-08 20:44         ` Phil Blundell [this message]
2016-01-11 19:10         ` Khem Raj
2016-01-11 19:52           ` Phil Blundell
2016-01-11 20:03             ` Khem Raj
2016-01-11 19:53           ` Andre McCurdy
2016-01-08 20:13     ` Phil Blundell

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=1452285883.1933.31.camel@pbcl.net \
    --to=pb@pbcl.net \
    --cc=armccurdy@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox