linux-mips-fnet
[Top] [All Lists]

Re: Indy crashes

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: Indy crashes
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Thu, 17 Feb 2000 15:27:11 +0100
Cc: "William J. Earl" <wje@cthulhu.engr.sgi.com>, linux-mips@vger.rutgers.edu, linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com
In-reply-to: <00bf01bf78ce$37cf6cc0$0ceca8c0@satanas.mips.com>
References: <00bf01bf78ce$37cf6cc0$0ceca8c0@satanas.mips.com>
On Wed, Feb 16, 2000 at 11:33:33PM +0100, Kevin D. Kissell wrote:

> > > 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.

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

<Prev in Thread] Current Thread [Next in Thread>