Subject: Re: Indy crashes

From: "Kevin D. Kissell" <[email-masked]>
Date: Wed, 16 Feb 2000 23:33:33 +0100

>Emprirically, it appears that the [R5000] manual is incorrect in regard
>to the number of nop instructions.  The above sequences are known
>to work (via years of testing, and also via validation in discussions
>with people familiar with the hardware pipelines).

In principle, I could check it against the RTL, but I probably
won't bother.  Many thanks for sharing the IRIX disassembly!

> > Thirdly, this whole thread underscores why "clever" solutions that 
> > depend on implementation features of particular CPUs should 
> > be avoided whenever possible. If you want to be assured of
> > getting a delay cycle in a MIPS instruction stream, you should
> > use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0),
> > which forces delays even in superscalar implementations.
>
>      This is not realistic, given the number of workarounds required
>for various processors, unless you are willing to have most processors
>run quite a bit slower.  (Extra cycles in utlbmiss are noticeable.)

I agree that it is not realistic to hav a single binary TLB miss handler
for all possible MIPS CPUs, but that's not what I was getting at.
I just consider it unwise to use the fact that one "knows" that branches 
"always" delay three cycles to avoid hazards.  Such tricks are 
obscurantist, and lead, in my experience, to errors.

            Kevin K.

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 17 Feb 2000 15:27:11 +0100

> obscurantist, and lead, in my experience, to errors.

Maybe but then again TLB exception handles aren't supposed to be hacked
by Joe Random Hacker.  There is more to know about the real silicon
beaviour than what the manuals say.  So for example some of the documentation
regarding c0 hazards on the R4000 is plain wrong for certain CPU revisions.

The TLB exception handlers really deserve a rewrite.  Somebody at QED
once called them the longest ones he has ever seen.

  Ralf