From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7642 invoked by alias); 29 Oct 2004 12:11:15 -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 7604 invoked from network); 29 Oct 2004 12:11:08 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sourceware.org with SMTP; 29 Oct 2004 12:11:08 -0000 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 612AFDC49; Fri, 29 Oct 2004 12:11:03 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id BBE8647207; Fri, 29 Oct 2004 12:11:10 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 783D075969; Fri, 29 Oct 2004 12:11:10 +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 A011247212; Fri, 29 Oct 2004 12:11:09 +0000 (GMT) Received: from terrorhawk (tigger.bri.st.com [164.129.15.24]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id AMK00455 (AUTH "andrew stubbs"); Fri, 29 Oct 2004 13:11:01 +0100 (BST) From: Andrew STUBBS To: "'Nick Clifton'" , "'Alexandre Oliva'" Cc: Subject: RE: Broken SH2a patches Date: Fri, 29 Oct 2004 12:11:00 -0000 Organization: STMicroelectronics Message-ID: <02e501c4bdb0$9f530b50$180f81a4@uk.w2k.superh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: <41821F69.4020604@redhat.com> X-SW-Source: 2004-10/txt/msg00461.txt.bz2 > > Nick, I take it that you didn't make any progress on them? >=20 > That would be correct. >=20 > Anyway as I understand it the problem is that the inheritance tree in=20 > sh-opc.h does not include the SH2A, right ? Judging from Alex's and=20 > Andrew's comments there are two possible fixes for this, a simple one=20 > that just adds the SH2A-nofpu and SH2A inheritance off the SH2E: > -------------------------------------------------------------- > --------- > /* Below are the 'architecture sets'. > They describe the following inheritance graph: >=20 > SH1 > | > SH2 > .------------'|`--------------------. > / | \ > SH-DSP SH3-nommu SH2E > | |`--------. |`--------. > | | \ | \ > | SH3 SH4-nommu-nofpu | | > | | | | | > | .------------'|`----------+---------. | | > |/ / \| | > | | .-------' | | > | |/ | | > SH3-dsp SH4-nofpu SH3E SH2A-nofpu > | |`--------------------. | | > | | \| | > | SH4A-nofpu SH4 SH2A > | .------------' `--------------------. | > |/ \| > SH4AL-dsp SH4A > -------------------------------------------------------------- No. This is wrong. There is _no_way_ a no-fpu variant can descend from an fpu variant - it would inherit the fpu! > And a complex one that invents a fake intermediate=20 > architecture to show=20 > the fact that the SH4, SH4A and SH2A share some instructions. To my=20 > mind however there is no satisfactory way of showing this,=20 > and instead I=20 > would like to suggest using a dotted line to show partial inheritance: > -------------------------------------------------------------- > ----------- > /* Below are the 'architecture sets'. > They describe the following inheritance graph: > (The .... between SH4A and SH2A-nofpu is a partial inheritance). >=20 > SH1 > | > SH2 > .------------'|`--------------------. > / | \ > SH-DSP SH3-nommu SH2E > | |`--------. |`------. > | | \ | \ > | SH3 SH4-nommu-nofpu | | > | | | | | > | .------------'|`----------+---------. | | > |/ / \| | > | | .-------' | | > | |/ | | > SH3-dsp SH4-nofpu SH3E | > | |`--------------------. | | > | | \| | > | SH4A-nofpu SH4 | > | .------------' `--------------------. | | > |/ \| | > SH4AL-dsp SH4A | > . | > ......... | > . | > SH2A-no-fpu > | > SH2A > -------------------------------------------------------------- I agree that there may be some problem inserting it into the diagram, but the important ting is that it must be inserted into the inheritance tree in the code and that the |s (ors) are removed from the instruction table (the op32 stuff may be ok, but the others have to go). Each and every instruction has to be introduced in one single architecture (albeit imaginary) and then be inherited by each and every one of its descendents. If this condition is not met then the algorithms in cpu-sh.c won't work and you find yourself forced to use the --isa option to sort out the mess. With the |s in place as they are the assembler _may_ work ok, but when it comes to save the file it has to translate that into an elf flag. When there are actually two architectures chosen (using | in the opcode table) then it can only choose one and the other information is lost. Therefore, when the file is loaded, the linker will not believe that it can link it against half the architectures it actually could link against. This is why you are forced to tell it which half manually using the -isa option. So lets consider the rules as I understand them (I haven't examined the opcodes table too carefully - this is just a thought experiment): - The sh2a_nofpu contains everything in sh2, some things from sh3_nommu, and some things of its own: SH2 | SH2A-nofpu-1 | \ SH3-nommu SH2A-nofpu - The sh2a contains everything from sh2a_nofpu, some things from sh3e, some things from sh4 and some things of its own: SH2A-nofpu | `--. SH2A-1 SH2A-2 | \ / | SH3E SH2A | | | `----. .----' SH4 I have omitted the SH3-* and SH4-* intermediates but you get the idea (you will need to consider if there any clashes with those as well). The SH2A-*-[12] variants contain those instructions which are present in both descendents - i.e. they are the common ancestor to which those instructions can be traced. I do not claim that the rules above are actually correct - I have gleaned them from memory of emails rather than solid facts - nor am I suggesting that the intermediate names are suitable. These are intended as a tutorial only. My other concern is the arch_op32 thingy. I don't know what it is for, or what the affect on the architecture code is, but you should be aware that it will not be encoded into the elf flags and, therefore, will not be available at link time. If it is only intended to be for the assembler then it may be ok. Once this is done you should create a small assembler file for each architecture the assembler and linker can produce (fake or real - they will all need elf codes assigned) and put it in the 'arch' testsuite directory (there is one under both the assembler and linker). If the architecture permutation test script produces the correct result then you know you have done the job right (but it will take some manual effort to verify the results first time). I hope that helps. I have tried to make sense but it isn't easy. It would be much easier if we forced the people who invented the SH family to maintain this themselves - sort of like house training. It does demonstrate why the old merge macro was doomed to failure. Good luck --=20 Andrew Stubbs andrew.stubbs@st.com andrew.stubbs@superh.com