public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@wasabisystems.com>
To: Andrew STUBBS <andrew.stubbs@st.com>
Cc: "'Nick Clifton'" <nickc@redhat.com>,
	"'Alexandre Oliva'" <aoliva@redhat.com>,
	<binutils@sources.redhat.com>
Subject: Re: Broken SH2a patches
Date: Fri, 29 Oct 2004 14:58:00 -0000	[thread overview]
Message-ID: <m3hdody3kj.fsf@gossamer.airs.com> (raw)
In-Reply-To: <02fd01c4bdc4$bd52b3d0$180f81a4@uk.w2k.superh.com>

Andrew STUBBS <andrew.stubbs@st.com> writes:

> The way you describe is, more or less what we used to have.

I see.  Thanks.

> This system already did work. It is just the new SH2A architecture patches
> which have broken it. The algorithm for determining what the most general
> architecture a file will execute on, based on the instruction used within
> that file, requires that individual instructions are only introduced to the
> inheritance graph in one place, and that once introduced they do not
> disappear from the descendents. It is difficult to think of any general
> algorithm that can cope with any other arrangement.

That's a tough restriction to impose, though.  In my experience new
variants of processors do borrow instructions from one another.
Requiring that each instruction be a member of a (possibly pseudo)
processor which is an ancestor of each processor which implements that
instruction is likely to be quite difficult going forward.  As new
processors come out, you will have to reshuffle the graph, introducing
new pseudo parent processors.

I gather that the goal is to precisely identify which processors may
execute a specific executable, based on the set of instructions which
appear in that executable.  Is having that precise information
especially useful for users in practice?  Would users be OK with
knowing "this was compiled for chip X, and will run on any chip which
supports this minimal ABI" even if it might run on some other chips
also?

Ian

  reply	other threads:[~2004-10-29 14:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-13 17:00 Andrew STUBBS
2004-10-28 20:33 ` Alexandre Oliva
2004-10-29 10:39   ` Nick Clifton
2004-10-29 12:11     ` Andrew STUBBS
2004-10-29 12:28       ` [OT] " Dave Korn
2004-10-29 12:59         ` Andrew STUBBS
2004-10-29 13:03           ` Dave Korn
2004-10-29 13:21             ` Andrew STUBBS
2004-10-29 13:59       ` Ian Lance Taylor
2004-10-29 14:35         ` Andrew STUBBS
2004-10-29 14:58           ` Ian Lance Taylor [this message]
2004-10-29 15:44             ` Andrew STUBBS
2004-11-08  9:04       ` Nick Clifton
2004-11-08 15:12         ` Andrew STUBBS
2004-11-08 16:27           ` Joern RENNECKE
2004-11-08 16:36           ` Joern RENNECKE
2004-12-15 17:11           ` Nick Clifton
2004-12-16 13:24             ` Andrew STUBBS
2004-12-20 17:18               ` Nick Clifton
2005-01-05 13:27                 ` Andrew STUBBS
2005-01-06 11:28                 ` Andrew STUBBS
2005-01-12 16:23                   ` Nick Clifton
2005-01-07 12:55                 ` Andrew STUBBS
2005-01-10 13:31                   ` Joern RENNECKE
2005-01-11 18:01                 ` Andrew STUBBS
2004-12-02 12:19 Andrew STUBBS

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=m3hdody3kj.fsf@gossamer.airs.com \
    --to=ian@wasabisystems.com \
    --cc=andrew.stubbs@st.com \
    --cc=aoliva@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=nickc@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).