From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3326 invoked by alias); 9 Nov 2004 17:00:35 -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 3235 invoked from network); 9 Nov 2004 17:00:27 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Nov 2004 17:00:27 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iA9H0Q3p004476 for ; Tue, 9 Nov 2004 12:00:26 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iA9H0Qr26184; Tue, 9 Nov 2004 12:00:26 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 20DC7129D8C; Tue, 9 Nov 2004 11:59:30 -0500 (EST) Message-ID: <4190F770.70006@gnu.org> Date: Tue, 09 Nov 2004 17:00:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: cgd@broadcom.com Cc: David Ung , gdb-patches@sources.redhat.com, nigel@mips.com Subject: Re: MIPS32 / MIPS64 release 2 support in simulator References: <1099495559.2778.53.camel@stockwell.mips.com> <1099576389.2778.90.camel@stockwell.mips.com> <418FA243.4060507@gnu.org> <1099937194.2780.151.camel@stockwell.mips.com> <4190EC00.6070501@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00164.txt.bz2 cgd@broadcom.com wrote: > At Tue, 09 Nov 2004 11:10:40 -0500, Andrew Cagney wrote: > >>David, this isn't a technical decision (if it were, Chris would be >>right). The new changes, or more exactly the new instructions, go in >>a new file clearly marked (C) FSF (and for that matter clearly stating >>that it was contributed by MIPS Inc). As for the mark-up of the >>existing instructions, that's mindnumming tedium. >> >>Sorry about this pedentary. I'm off to pester another lawyer. > > > Andrew, > > Once the legal issues are resolved on your end, will be it be > acceptable from your POV to merge them all into mips.igen? > > Or do you believe they should always be separate? That's a technical question, as I shouldn't, I don't care! > (Why is this necessary now, when it wasn't necessary back when we > contributed the original mips32/mips64 support?) That was a screw-up on my part. You'll see I more recently integrated the altivec instructions into the PPC as a separate file. Andrew