This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] make MIPS sim mips.igen model names one per line.


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:

<mips isas, one per line or many per line>
<one vendor's models>
<another vendor's models>
<another vendor's models>

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]