Re: [RFA] MIPS 24K Errata Patch

[Richard Sandiford <rdsandiford at googlemail dot com>]

Catherine Moore <clm@codesourcery.com> writes:
> I've attached updated patches for the testsuite and the assembler.  I 
> think that I've addressed all of your comments.  Do these new patches 
> now look okay?

Thanks for the updates.  They look good apart from a few minor
stylistic nits.  I'm still not sure about the last point though:

[ Hmm, I see I got the hex offsets wrong last time, sorry.  I realise
  it probably didn't make much sense with those mistakes. ]

 The last case is interesting.  Does the errata still trigger if
 a suxc1 instruction straddles a cache boundary?  E.g., playing
 battleships for a moment:

     0 2 4 6
   0 ........
   8 ........
  10 ........
  18 ....XXXX   suxc1 to 0x1C
  20 XXXX....
  28 ........
  30 ..XX....   sh to 0x32
  38 ......XX   sh to 0x3E

 It looks like the range checks will return 0 in this case, even though
 all three stores write to different doublewords of the second cache line.

 The answer might well be "yes, the errata doesn't trigger for this case".
 If so, it'd be worth mentioning that in the main comment.  The answer
 affects what the comments above the remaining 24 and 32 checks should be.

What I meant was that:

  pos[0].off == 0x1C
  pos[1].off == 0x32
  pos[2].off == 0x3E

and so:

  if (pos[2].off - pos[1].off >= 24
      || pos[1].off - pos[0].off >= 24
      || pos[2].off - pos[0].off >= 32)
    return 0;

would say that no nops are needed here.  However, all stores are writing
to different doublewords of the second cache line, and from a naive
reading of the the errata description, that means that the errata
could trigger.

Which is right?  If the code is right, then the errata description
needs a bit more detail.  If the naive reading of the errata is right,
then the code needs to change.

Richard