From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14278 invoked by alias); 16 Dec 2004 13:24:25 -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 14137 invoked from network); 16 Dec 2004 13:23:52 -0000 Received: from unknown (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org with SMTP; 16 Dec 2004 13:23:52 -0000 Received: from lon-inc-03.spheriq.net ([195.46.50.67]) by lon-del-01.spheriq.net with ESMTP id iBGDNqwE026609 for ; Thu, 16 Dec 2004 13:23:52 GMT Received: from lon-out-02.spheriq.net (lon-out-02.spheriq.net [195.46.50.130]) by lon-inc-03.spheriq.net with ESMTP id iBGDNpEs019491 for ; Thu, 16 Dec 2004 13:23:51 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-02.spheriq.net with ESMTP id iBGDNoa2028956 for ; Thu, 16 Dec 2004 13:23:51 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id iBGDNmjA001222 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 16 Dec 2004 13:23:50 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B4242DA45; Thu, 16 Dec 2004 13:23:47 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 1456F47258; Thu, 16 Dec 2004 13:24:15 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9D9717599B; Thu, 16 Dec 2004 13:24:15 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C6A1947258; Thu, 16 Dec 2004 13:24:14 +0000 (GMT) Received: from terrorhawk (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id AQG02051 (AUTH "andrew stubbs"); Thu, 16 Dec 2004 13:23:45 GMT From: Andrew STUBBS To: "'Nick Clifton'" Cc: "'Alexandre Oliva'" , , "'Joern RENNECKE'" Subject: RE: Broken SH2a patches Date: Thu, 16 Dec 2004 13:24:00 -0000 Organization: STMicroelectronics Message-ID: <01bf01c4e372$a1525180$0d0f81a4@uk.w2k.superh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: <41C06DE2.1070806@redhat.com> X-O-Virus-Status: No X-O-URL-Status: Not Scanned X-O-CSpam-Status: Not Scanned X-O-Spam-Status: Not scanned X-O-Image-Status: Not Scanned X-O-Att-Status: No X-SpheriQ-Ver: 1.8.3 X-SW-Source: 2004-12/txt/msg00188.txt.bz2 Hi Nick, > Features of this patch include: >=20 > * I did not try to update the ASCII art in sh-opc.h with the new=20 > relationships. In my opinion it just makes the diagram too=20 > cluttered to=20 > be useful anymore. Hmmm. That may be true, but I don't like it. Here's my bash at it (note that the inheritance isn't quite as you had it - see below): SH1 | SH2 .------------'|`--------------------------------. / | \ SH-DSP SH3-nommu/SH2A-nofpu SH2E | | |`--------------------. | | | | \| | SH3-nommu SH4-nm-nf/SH2A-nofpu SH3E/SH2A | |\ | | | | | | `------. | SH2A-nofpu | | | | \| \ | | | SH3 SH4-nommu-nofpu `---------+---. | | /|\ | | \| | .-----------' | `--------+---------------------. | SH4/SH2A |/ | / \| | | | .-------' | | | |/ | | SH3-dsp SH4-nofpu SH3E /| | |`-------------------------------. | .-' | | | \|/ | | SH4A-nofpu SH4 SH2A | .------------' `-------------------------------. | |/ \| SH4AL-dsp SH4A Probably there ought to be a comment associated with the diagram explaining that SHx/SHy refers to the intersection between the two architecures. Alternatively the intersections could be made less confusing/dominant by replacing their names with letters and then adding a legend (perhaps also with details of shifts and prefetch differences). > * I have tried to use more meaningful names for the new=20 > machine values. >=20 > * I have added tests for the new machine values to the SH=20 > specific=20 > parts of the GAS and LD testsuites. >=20 > What do you think ? These are all good things, and now there is a problem highlighted in the test results: One example: + sh2a-nofpu-or-sh3-nommu.s -isa=3Dsh2e sh2a-or-sh3e When -isa=3Dsh2e it shouldn't be able to output any other isa, but it clear= ly is. This is repeated many times. I think this is down to the fact that you haven't created any new base architectures, but instead ored them together: ! #define arch_sh2a_or_sh3e (arch_sh2a_base|arch_sh3_base) I haven't proven this though. In addition to this, the inheritance tree still isn't quite right. I'm beginning to think that if the head maintainer can't get this right then it must be too complicated. I can't think of a better way though. Whatever technique we use it needs to be able to select an architecture, based on the instructions in the file, that specifies what architecture the file will run on, without excluding any other similar, but different, architectures that it may also run on (hence the fake architectures). Any ideas? Specifically the problem is here #define arch_sh3e_up (arch_sh3e | arch_sh2a_or_sh4_up) and here #define arch_sh3_nommu_up (arch_sh3_nommu \ | arch_sh3_up | arch_sh2a_nofpu_or_sh4_nommu_nofpu_up) Both these inheritances cause SH2A to allow SH3 instructions. E.g. 'ldc Rn, SSR', 'ldc Rn, Rn_BANK' etc. According to the document I have from the Renesas web site the SH2A does not have such instructions. Joern and I therefore think that the SH2A may descend from nothing but the SH2 and SH2e, and instead it conceptually introduces some of the instructions used by the SH3 and SH4. The diagram above shows this, but we have not checked this instruction-by-instruction. The code would then read: /* Central branches. */ #define arch_sh1_up (arch_sh1 \ | arch_sh2_up) #define arch_sh2_up (arch_sh2 \ | arch_sh2e_up \ | arch_sh2a_nofpu_or_sh3_nommu_up \ | arch_sh_dsp_up) #define arch_sh2a_nofpu_or_sh3_nommu_up (arch_sh2a_nofpu_or_sh3_nommu \ | arch_sh2a_nofpu_or_sh4_nommu_nofpu_up \ | arch_sh2a_or_sh3e_up \ | arch_sh3_nommu_up) #define arch_sh2a_nofpu_or_sh4_nommu_nofpu_up (arch_sh2a_nofpu_or_sh4_nommu_nofpu \ | arch_sh2a_nofpu_up \ | arch_sh4_nommu_nofpu_up) #define arch_sh2a_nofpu_up (arch_sh2a_nofpu \ | arch_sh2a_or_sh4_up) #define arch_sh3_nommu_up (arch_sh3_nommu \ | arch_sh3_up \ | arch_sh4_nommu_nofpu_up) #define arch_sh3_up (arch_sh3 \ | arch_sh3e_up \ | arch_sh3_dsp_up \ | arch_sh4_nofp_up) #define arch_sh4_nommu_nofpu_up (arch_sh4_nommu_nofpu \ | arch_sh4_nofp_up) #define arch_sh4_nofp_up (arch_sh4_nofpu \ | arch_sh4_up \ | arch_sh4a_nofp_up) #define arch_sh4a_nofp_up (arch_sh4a_nofpu \ | arch_sh4a_up \ | arch_sh4al_dsp_up) /* Right branches. */ #define arch_sh2e_up (arch_sh2e \ | arch_sh2a_or_sh3e_up) #define arch_sh2a_or_sh3e_up (arch_sh2a_or_sh3e \ | arch_sh2a_or_sh4_up \ | arch_sh3e_up) #define arch_sh2a_or_sh4_up (arch_sh2a_or_sh4 \ | arch_sh2a_up \ | arch_sh4_up) #define arch_sh2a_up (arch_sh2a) #define arch_sh3e_up (arch_sh3e \ | arch_sh4_up) #define arch_sh4_up (arch_sh4 \ | arch_sh4a_up) #define arch_sh4a_up (arch_sh4a) /* Left branch. */ #define arch_sh_dsp_up (arch_sh_dsp \ | arch_sh3_dsp_up) #define arch_sh3_dsp_up (arch_sh3_dsp \ | arch_sh4al_dsp_up) #define arch_sh4al_dsp_up (arch_sh4al_dsp) Please check this over yourself, but it looks right to me. I'm pretty sure it matches the diagram above, but I'm not certain that both match the SH2A architecture. There's plenty of room for screw ups here. We're thinking about ways to automate/simplify this stuff, but nothings going to happen this year I wouldn't think. --=20 Andrew Stubbs andrew.stubbs@st.com (aka. andrew.stubbs@superh.com)