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

cgd
2004-03-25T07:15:08Z

[ 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