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

Re: CVS 2.3.10 + framebuffer + keyboard, DS5000/200

To: Ryan Rafferty <rraffer1@osf1.gmu.edu>
Subject: Re: CVS 2.3.10 + framebuffer + keyboard, DS5000/200
From: Dominic Sweetman <dom@algor.co.uk>
Date: Wed, 6 Oct 1999 09:41:31 +0100 (GMT/BST)
Cc: linux-mips@fnet.fr, linux@engr.sgi.com, linux-mips@vger.rutgers.edu
In-reply-to: <Pine.OSF.3.96.991005224010.29991B-100000@osf1.gmu.edu>
References: <19991006015410.A19750@uni-koblenz.de> <Pine.OSF.3.96.991005224010.29991B-100000@osf1.gmu.edu>
Ryan wrote:

> It seems in my opinion that the programmer-visible TLB cache in the R4k
> series was a "feature" that has caused more difficulty for OS programmers
> using the MIPS architecture than anything else that I can think of; do any
> other architectures currently employ this type of cache? Or is there a
> solid advantage to making the TLB visible (as opposed to the transparent
> nature of caches on x86, etc)?
> 
> I think I remember that some members of the R4xxx family eschewed the
> original TLB scheme of the R4000 et. al.

No, MIPS CPUs have never had anything but a software-managed TLB.
Microcode-driven multi-cycle hidden events are not the MIPS way!

It was a good decision back in 1985, when MIPS Corp had to add virtual
memory to an academic project with minimum design time and silicon
area.  Their tiny OS team had a solid BSD unix running on their
hardware remarkably quickly.

There are certainly some sources of confusion:

o The TLB is conceived as a hardware/software design, but the software
  concepts are not really presented in any of the CPU manuals.  I
  suppose I should recommend you to read my book on MIPS...

o There are two quite different implementations (broadly speaking one
  for the R3000 and its descendants, and another for the R4000
  onward).  And then there are minor differences between those.

o The software TLB means that there is more than one way to do it.
  OpenBSD (at least) turns its back on the hardware hints - which make
  a conventional memory-resident page table attractive - and uses the
  TLB refill exception handler to implement a second-level,
  memory-resident cache of translations.  It's not so efficient, but
  it does allow more of the VM code to be machine-independent.

More than anything, it all depends where you start from.  MIPS has
just about the simplest translation hardware of any viable VM
architecture, and if your kernel started there it would have little
difficulty dealing with more sophisticated systems.  Perhaps the Linux
kernel's portability is suffering from spending a lot of its time
mixing with x86 CPUs?

Dominic Sweetman
Algorithmics Ltd

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