From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24648 invoked by alias); 29 Oct 2004 14:58:49 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 22175 invoked from network); 29 Oct 2004 14:57:58 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 29 Oct 2004 14:57:58 -0000 Received: (qmail 9265 invoked by uid 10); 29 Oct 2004 14:57:57 -0000 Received: (qmail 31864 invoked by uid 500); 29 Oct 2004 14:57:48 -0000 Mail-Followup-To: nickc@redhat.com, aoliva@redhat.com, binutils@sources.redhat.com, andrew.stubbs@st.com From: Ian Lance Taylor To: Andrew STUBBS Cc: "'Nick Clifton'" , "'Alexandre Oliva'" , Subject: Re: Broken SH2a patches References: <02fd01c4bdc4$bd52b3d0$180f81a4@uk.w2k.superh.com> Date: Fri, 29 Oct 2004 14:58:00 -0000 In-Reply-To: <02fd01c4bdc4$bd52b3d0$180f81a4@uk.w2k.superh.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-10/txt/msg00469.txt.bz2 Andrew STUBBS 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