From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21256 invoked by alias); 8 Nov 2004 18:06:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21062 invoked from network); 8 Nov 2004 18:06:45 -0000 Received: from unknown (HELO dmz.algor.co.uk) (62.254.210.145) by sourceware.org with SMTP; 8 Nov 2004 18:06:45 -0000 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1CRE2o-0000FB-00; Mon, 08 Nov 2004 18:15:10 +0000 Received: from stockwell.mips.com ([192.168.192.238]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1CRDuU-0002wD-00; Mon, 08 Nov 2004 18:06:34 +0000 Subject: Re: MIPS32 / MIPS64 release 2 support in simulator From: David Ung To: Andrew Cagney Cc: cgd@broadcom.com, gdb-patches@sources.redhat.com, nigel@mips.com In-Reply-To: <418FA243.4060507@gnu.org> References: <1099495559.2778.53.camel@stockwell.mips.com> <1099576389.2778.90.camel@stockwell.mips.com> <418FA243.4060507@gnu.org> Content-Type: text/plain Organization: MIPS Technologies UK Message-Id: <1099937194.2780.151.camel@stockwell.mips.com> Mime-Version: 1.0 Date: Mon, 08 Nov 2004 18:06:00 -0000 Content-Transfer-Encoding: 7bit X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.833, required 4, AWL, BAYES_00) X-SW-Source: 2004-11/txt/msg00135.txt.bz2 On Mon, 2004-11-08 at 16:43, Andrew Cagney wrote: > cgd@broadcom.com wrote: > > At Thu, 4 Nov 2004 13:53:38 +0000 (UTC), "David Ung" wrote: > > > >>I shall update mips.igen with the new r2 instructions and then submit it > >>as a patch. > > > > > > cool, thanks. > > Don't. These new changes go in a new file, and that file gets a very > clear FSF copyright. > > Andrew > arhh. Chris's argument of that the rest of the tools consider rev 2 instructions as an ISA is quite a valid one. And for consistency with the existing structure, it looks to be the right thing to do. But when I got to merging in the r2 instructions into mips.igen, I do see that for every mips32 / 64 instruction, I now have to also tag them mips32r2 / 64r2. It would probably be nicer to just tell it to include all the mips32 instructions (which would be like treating it as an ASE). But then again it brings us back to the original argument, and I probably would lean slightly towards the ISA model and be part of mips.igen depite polluting the whole file with *mips32r2: and *mips64r2: tags. David.