From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17441 invoked by alias); 11 Feb 2002 21:44:20 -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 17370 invoked from network); 11 Feb 2002 21:44:19 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sources.redhat.com with SMTP; 11 Feb 2002 21:44:19 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Mon, 11 Feb 2002 13:44:01 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-2.sj.broadcom.com (mail-sj1-2 [10.16.128.232]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g1BLiIKf011384; Mon, 11 Feb 2002 13:44:18 -0800 (PST) Received: (from cgd@localhost) by mail-sj1-2.sj.broadcom.com ( 8.9.1/SJ8.9.1) id NAA25044; Mon, 11 Feb 2002 13:44:18 -0800 (PST) To: fche@redhat.com cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] make MIPS sim mips.igen model names one per line. References: From: cgd@broadcom.com Date: Mon, 11 Feb 2002 13:44:00 -0000 In-Reply-To: fche@redhat.com's message of "11 Feb 2002 16:18:47 -0500" Message-ID: X-Mailer: Gnus v5.7/Emacs 20.4 MIME-Version: 1.0 X-WSS-ID: 1076E4AB2922164-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00335.txt.bz2 At 11 Feb 2002 16:18:47 -0500, fche@redhat.com wrote: > cgd@broadcom.com writes: > I must admit I don't see the point of this specific grasp for > consistency. The single-line format allows compactness; the > multi-line format allows greps and other line-by-line source > manipulations. These are both useful in their place. In this case, I fail to see how _mixing_ them in mips.igen for a single set of ISAs (the standars mipsI ... mipsIV, and soon to be mips32, mips64), is the right thing. One way or the other, I think it should be consistent at least for the MIPS ISA 'models'. There's no reason to have inconsistency. > Have you actually encountered the maintainability issues you mention > ([more?] "conflicts/patched lines")? Were they really troublesome? > Given the preferred use of context diffs, it doesn't seem like > > A > B > CHANGE > D > E > > is any less likely to get conflicts than > > A,B > CHANGE > D,E I think we've seen _a little_ in terms of that, but really it's not been _too_ large a problem because, uh, hardly anybody has changed the code in a long time. 8-) I think I've heard some people (at RH, adding new model names to the sim stuff) indicate that one-per-line is better for them. That was like a year and a quarter ago, though, so maybe i'm misremembering. It can actually help in practice to reduce cvs merge conflicts. Consider: A B C modified by one person to be: A NEW_1 B C and modified by another to be: A B NEW_2 C CVS will resolve properly w/o a conflict. in mips.igen, there typically _will_ be lines between added model name lines, because normally you have: etc. and often if you're working independently you're adding things to different vendor model lists. (Of course, as it is now, those are already one-per-line.) So, in a nutshell: (1) it can help some in general, (2) the place where it would help most is already one-per-line, (3) right now, for the stock MIPS ISAs 'models', the usage is mixed, and there's no reason for that. (4) there _is_ a bit of benefit to having one per-line even for the stock MIPS ISAs. Eric's going to be folding in the mips32/mips64 stuff soon. I've got similar changes, and also mipsV changes. So there will be some merging in the future, and having one-per-line will help there. Also, it's not as easy to go the other way than it is to split things to be one per line. (My change was constructed via: :g/^\*/s;,;:^M*;g Going the other way isn't so easy. 8-) chris