Re: [rfa/mips] Second go at vr5500 hilo hazard fix

[cgd@broadcom.com]

[ 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