From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 327 invoked by alias); 3 Dec 2002 17:35:58 -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 309 invoked from network); 3 Dec 2002 17:35:56 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 3 Dec 2002 17:35:56 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 717753E4B; Tue, 3 Dec 2002 12:35:49 -0500 (EST) Message-ID: <3DECEB75.8090005@redhat.com> Date: Tue, 03 Dec 2002 09:35:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cgd@broadcom.com Cc: Richard Sandiford , gdb-patches@sources.redhat.com Subject: Re: sim/mips patch: add support for more NEC VR targets References: <3DE417F8.8030209@redhat.com> <3DE4379F.4030209@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00080.txt.bz2 > At Wed, 27 Nov 2002 03:10:50 +0000 (UTC), "Andrew Cagney" wrote: > >> This is the way it has (ment to) been done for all MIPS ISA variants >> since igen replaced gencode. You've proposed a change to that process >> so I'm [trying to] explain the rationale behind the current status-quo :-) > > > Ahh. OK, I misinterpreted what you were trying to say. > > So, all of that having been said, do you have strong objections to > proceeding in the "new way" as described here in previous messages? > > (You have the right automatically reserved to tell me "I told you so" > if it turns out to be impractical. 8-) If the function is going to contain: if (TARGET_ARCH (SD) == ...) then I don't think it should be in the .igen file (i.e., put it somewhere else as is done with the FP code (where I can't see it :-)). The .igen files have a mechanism for differentiating between architecures, so I don't think that file should be confused by using a second mechanism. If igen ever gets finished (the C code is replaced by a language parser) then the simpler that language is the better. Part of that simplicity is avoiding dependencies on SD / sim-main.h like the plague :-) As for having to tag each individual entry in the .igen file with an explicit CPU. Yes, that sux. However, I also believe that it has significantly reduced the overall error rate (no more breaking one target by editing another) and that benefit vastly outweighs the short term pain. Andrew