From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5402 invoked by alias); 25 Mar 2004 07:15:08 -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 5362 invoked from network); 25 Mar 2004 07:15:06 -0000 Received: from unknown (HELO mms2.broadcom.com) (63.70.210.59) by sources.redhat.com with SMTP; 25 Mar 2004 07:15:06 -0000 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 24 Mar 2004 23:14:45 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA10685; Wed, 24 Mar 2004 23:14:17 -0800 (PST) Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id i2P7Enov008766; Wed, 24 Mar 2004 23:14:49 -0800 (PST) Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com ( 8.11.6/8.9.3) id i2P7EnU04312; Wed, 24 Mar 2004 23:14:49 -0800 X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f To: "Richard Sandiford" cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Second go at vr5500 hilo hazard fix References: <87oequw5xw.fsf@redhat.com> <87znadvpr7.fsf@redhat.com> From: cgd@broadcom.com Date: Thu, 25 Mar 2004 07:15:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 6C7C596F1PW4330932-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00598.txt.bz2 [ chunks of reply re-ordered. also, sorry for the delay, i've been swamped. ] At Thu, 18 Mar 2004 20:55:56 +0000, Richard Sandiford wrote: > Well, I had a similar check in: > > http://sources.redhat.com/ml/gdb-patches/2002-11/msg00642.html > > OK, so it wasn't wrapped up in a nice macro, it just checked the > architecture directly: > > + /* There are no timing requirements in vr5500 code. */ > + if (MIPS_MACH (SD) == bfd_mach_mips5500) > + return 1; Yes, I know. (You also did it in one place rather than three, i.e., didn't split it along the current check_* fn lines... though i don't recall how much i changed them when I cleaned that code up a couple (?) of months ago.) > 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. I still take issue with the latter ("short term pain"), for such additions have to stay in for the life of support for the arch in the simulator, which *should* be quite long term. > But that was exactly what Andrew objected to: And he and I (strongly, IMO) disagreed at that time. (IIRC, I think I mentioned at the time that the right solution to this is better testing. I still think that's true.) Of course, in August of last year, (unprompted by me!) he decided to stop being MIPS co-maintainer. So, at this point, I'm the approval authority, and I like my style of patch most. 8-) I would like to see it augmented to include some test code (now that there's a prelim test framework for mips, with what, 1 test? 8-), but as long as you commit to actually doing that I'm OK with it waiting a little bit. If this is not an acceptable solution to Andrew (as a global maintainer), then my back-off position is make MIPS IV follow the MIPS architecture documentation, and make all "MIPS IV-ish" processors which are documented to not act like MIPS' MIPS IV definition be "MIPS III +". That is more technically correct from an architecture POV than the current MIPS IV definition, unless somebody's got some MIPS IV documentation that contradicts the current MIPS specs. Note that I most decidedly do *not* think that is the right solution. cgd