MIPS: MMU, paging, memory description?

[Artlav]

Hello.

I'm looking for a description of common MIPS virtual memory management (R4000 style MMU).

What i can find is either very shallow and generic descriptions, or very detailed and precise architecture reference.
The first does not tell anything about how it all is supposed to work, not even how TLB relate to memory, the latter tells all the meanings of every single bit, without giving any overview of the big picture, like how TLB relate to memory and what maps what.

So, can anyone help me find a comprehensive description of just how does that MMU works?
Something like http://wiki.osdev.org/Paging , only for MIPS.

[Combuster]

Since you don't want to dig through the manuals to get the picture yourself, I'll just post what general knowledge and a small number of google queries told me:

The key difference between MIPS and x86 is that the former uses a manual TLB whereas the latter has an automatic TLB. On MIPS, you are free to create and manage your own paging structures, and when you want a process to be able to access memory (typically done on a pagefault) you manually have to write a TLB register to map a certain range of virtual memory to physical memory.

The processor will probably be able to tell you the amount of TLB slots. You can write a specific slot using the TLBWI opcode (translation lookaside buffer write indexed), or you can let the MMU select a slot using TLBWR (translation lookaside buffer write random). Since either opcode takes more than a register worth of data (source start, dest start, page size, control bits, tags, etc), you will need to send the data in parts to the coprocessor using several MTC0 instructions, after which the TLB* instructions will collect the relevant coprocessor registers and write them to the TLB.

For any more details, do your homework. You have TFM, just R it

[Artlav]

Thanks, the key word was software-controlled TLB.
It's a concept i never even imagined, so with that figured out everything in that big f manual fell into place.

I wonder how it compares to hardware one?
Getting an exception nearly every time a large program with random access tries to access the memory does not sound even remotely fast.
Nor does OS code feels easy.

But, with these problems solved (that MIPS laptop works quick enough, so they can be solved), the possibilities seem rather interesting.

Two years ago you said you'd willing to try it one day, did that day ever come?

[Colonel Kernel]

I wonder how it compares to hardware one?

That depends a lot on how you implement your paging structures. From a hardware point of view, manual TLB management has a much lower transistor cost, but I don't think that's what you were asking.

Getting an exception nearly every time a large program with random access tries to access the memory does not sound even remotely fast.

That's why the TLB is there. You would only get an exception on TLB misses, not on every memory access. Your TLB miss handler would obviously not be allowed to generate any TLB misses itself.

[gravaera]

I wonder how it compares to hardware one?

TLB is still a hardware feature :O Its just its behaviour that's a bit different.

Getting an exception nearly every time a large program with random access tries to access the memory does not sound even remotely fast.

It's not much different from hardware assisted TLB loading. See http://wiki.osdev.org/Memory_Management_Unit .

--Peace out
gravaera