At Thu, 18 Mar 2004 15:06:42 +0000 (UTC), "Richard Sandiford" wrote:
> Various suggestions were made about how this could be handled, but I
> think Andrew's position remained the same: we shouldn't try to treat the
> vr5500 ISA as "MIPS IV plus a bit and minus a bit" (my words, not his).
> He reckoned every vr5500 instruction should be marked as such.

My reading is, unfortunately, is that it is a *correct* implementation
of the MIPS ISA.

At least according to the "Historical information" in the MIPS64 AFP
Volume II (Basic Instruction Set) -- I'm looking at revisions around
1.0 here -- the 3-cycle hi/lo hazards should only have been a problem
for MIPS I-III.

I.e., MIPS IV processors which *have* these hi/lo hazards are the
things broken... but as you note at least according to the 5400 docs,
it is MIPS IV and does have the hazard.


(I thought Andrew's biggest objection was stuffing bfd_* values into
mips.igen, but I may be wrong on that.  It's been a while.)


> The patch below does this.  Tested on mips64vrel-elf.  OK to install?

Doing this doesn't seem satisfactory to me.  It would open the door to
a very similar modification, for another handful of processors, which
would be really quite out of hand IMO.


Now that the mips sim 'multi' bits are in place (including good
default), and we have MIPS_MACH(SD) (thanks! 8-), it should be
possible to code a simple macro which checks for the appropriate bfd
machine, and decides whether interlocks are present.

I'd rather see an implementation that acts somewhat like the (rough,
uncompiled, not sanity-checked) patch below.  Additional advice: make
sure the comment describing the new macros mentions the fact that they
should have cases only for certain ISAs' processors (mipsIV, mipsV).

The names were just a suggestion.  there are probably better, shorter
ones, and I didn't try to reconcile them with any other code (e.g. the
code in headers where they might be defined 8-).


This type of change has the "right" properties, IMO:

        * boils down to a no-op if not multi.

        * doesn't impact ISAs with no hazard ambiguity if multi.

        * shouldn't cause maint pain long term if everybody decides to
          make the code right for their fave MIPS IV arch.  8-)



cgd