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

Re: Linux/MIPS for DECstations...

To: linux-mips@fnet.fr
Subject: Re: Linux/MIPS for DECstations...
From: Dom Sweetman <dom@algor.co.uk>
Date: Wed, 1 Oct 1997 22:33:26 +0100 (BST)
In-reply-to: <XFMail.971001200907.harald.koerfgen@netcologne.de>
References: <199709302112.OAA04252@dull.cobaltmicro.com> <XFMail.971001200907.harald.koerfgen@netcologne.de>
Harald Koerfgen (harald.koerfgen@netcologne.de) writes:

> After carefully re-resing the IDT Manual ant glance at the SGI
> Manual, it is my understanding, that indeed there is a difference in
> the exception mechanism between the R3000 and the R4000.

Yes, there are some very big differences concealed behind what look
like almost the same registers...

> R4000: *All* TLB misses cause a TLB refill exception. If a TLB miss
> happens in the exception routine itself...

Strictly speaking, that's "if a TLB miss happens with the status
register exception level bit set" - SR(EXL) for short.  But you're
right, the only time that will actually happen will be the TLB miss
incurred by the table look-up of the fast TLB miss.

> ..., a TLBL or TLBS exception is caused. This is handled
> bye the general exception handler.

> R3000: *Only* references to KSEG0 (0x00000000- 0x7fffffff) may cause
> a TLB exception.  TLB misses with references to KSEG2 (0xc0000000 -
> 0xffffffff !!!) cause a TLBL or TLBS exception, which is handled by
> the general exception handler.

That's right; so unix application TLB misses are handled fast, but any
kernel-translation misses get a bigger penalty.  It's up to the OS
writer to minimise the latter.

Both mechanisms support the mechanism built around the "Context"
register which helps out a translation scheme using a main page table
which is apparently "flat" but is actually located in kernel virtual
memory.

But yes, Harald, that sounds right.

PS: I wrote most of the IDT manual, so I hope it helped...  My
    forthcoming book has the R4x00 stuff in too, and should be out
    next year, pub Morgan Kaufmann.

Dominic Sweetman
Algorithmics Ltd
dom@algor.co.uk

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