MMU in Software

[srg]

Hi all, I was wondering.

Just out of interest, for fun, would it be possible for an operating system that ran on a line of CPU's that some did and some didn't have MMUs buy emulating one in software.

So on a 68030 it would use the hardware built in one, but on the 68EC030 it would use the software MMU emulator.

I bet this could be taken further and act as a low level emulator to smooth out the segmentation on the 80286 protected mode, so according to the rest of the system, the machine would have a 16MB flat address space.

Of course this "SoftMMU" would be written in asm for speed and would have to be highly hand optimised, but could it be made fast enough not to slow the whole machine to a crawl.

just a fun thought (adding brain cells to "Brain Damaged" CPUs ;D )

srg

[Dreamsmith]

Err, emulating an MMU does not work like emulating an FPU, where you simply catch any FPU-missing exceptions and do what the FPU would have done. You can write an FPU emulator that works reasonably fast because, when there's no FPU, anything that would access the FPU causes an exception instead.

The MMU, on the other hand, is used by each and every instruction on the processor that in any way references memory, and if one is not available, no exceptions are generated (indeed, the MMU is the hardware that usually generates memory exceptions; without one, you can access even nonexistent memory without causing an exception). To emulate an MMU would require emulating the CPU entirely, which would slow the machine to a crawl. For an example of an MMU emulator, see Bochs.

[Dreamsmith]

Of course, no sooner do I make such statements than I think of workarounds. You could emulate an MMU by causing all memory references to generate an exception, which could be accomplished by making sure all loads to segment registers actually load zero. Thus, the processor would book along through instructions that don't reference memory without causing any exceptions, but any memory reference would be caught by the exception handler and emulated. You of course also catch any attempt to set the segment registers and emulate that (as long as you keep the actual GDT free of valid segments and fake a virtual GDT for the program, same with LDT, this could work).

Note: This would probably be slower than simply emulating the CPU entirely, ala Bochs, but it could be done!

[Dreamsmith]

Whoops, fly in the ointment:

Code: Select all

    MOV AX,DS

To properly emulate this, AX would need to be loaded with the virtual DS value, not the actual zero you stored there, but since this instruction doesn't reference memory, it won't trigger an exception.

Shoot, I thought I had it. Hmmm. Of course, it's easy (but pointless?) to emulate an MMU on a system with an MMU. The problem on a system with no MMU is there's no way to cause all attempts to access memory cause an exception in a transparent manner. It seems an MMU is required in order to emulate one...

[srg]

Whoops, fly in the ointment:

Code: Select all

    MOV AX,DS

To properly emulate this, AX would need to be loaded with the virtual DS value, not the actual zero you stored there, but since this instruction doesn't reference memory, it won't trigger an exception.

Shoot, I thought I had it. Hmmm. Of course, it's easy (but pointless?) to emulate an MMU on a system with an MMU. The problem on a system with no MMU is there's no way to cause all attempts to access memory cause an exception in a transparent manner. It seems an MMU is required in order to emulate one...

hmm On a 286 segmentation flattener, all segment register changes would be done by the flattener, not emulated. What I meant was would it be possible to hide from the main part of the OS the segmentation, or the fact there is no MMU (depending on the CPU).

In this case, an OS's memory manager (the normal part) would be blissfully unaware that the machine had no MMU or had segmentation (take you pick if it's a 68K or 286) and would carry on regardless. Then the segmentation "flattener" on 286 or "SoftMMU" on both fill in the details.

So you could say that the segmentation flattener created a "virtural" flat addressing mode. This would enable a kernel designed for, say, a 386 with flat addressing to work on a 286, because the segmentation is hidden from it.

I hope I havn't confused you

srg

[Dreamsmith]

Well, first of all, if you're attempting to use a flat memory model, just setup your segments accordingly at bootup and ignore them from then on. No need for any kind of emulation in that case.

Secondly, segmentation has absolutely positively nothing at all do to with the MMU, nor would emulating an MMU in any way affect segmentation, as these are unrelated issues.

And finally, once again, emulating an MMU requires emulating every instruction on the processor that accesses memory. This pretty much limits you to emulating the CPU entirely.

[Arto]

Yep, that's what QEMU does:

In order to be able to launch any OS, QEMU also supports a soft MMU. In that mode, the MMU virtual to physical address translation is done at every memory access. QEMU uses an address translation cache to speed up the translation.

In order to avoid flushing the translated code each time the MMU mappings change, QEMU uses a physically indexed translation cache. It means that each basic block is indexed with its physical address.

When MMU mappings change, only the chaining of the basic blocks is reset (i.e. a basic block can no longer jump directly to another one).

[srg]

ok ok throw out the MMU emulator idea.

Now, for the seperate issue (I knew these were seperate issues, sorry if I confused you) of the 286 segment "flatener", you can't use a flat segment addressing scheem in 286 PMode because segmetns can only be 64K is size.

I was giving it some furthor thought and there might be two possible ideas. First of all you could do similar to what huge mode in real mode compilers and have 24 bit pointers and calls for everything. The segments would basically be lined up nose to tail so when 24 bit far points and calls would be used, it would seem flat, although segment swapping would be slow.

Another little idea is that segment base addresses could be swapped between descriptor and descriptor (again segments would be nose to tail) which would make a kind of virtual memory with a 64K granuality (the segment registers simply hold selectors to a discriptor, so changing the segment base in the descriptor without changing the selector value would alter the address of the segment surely.

srg

[Dreamsmith]

Now, for the seperate issue (I knew these were seperate issues, sorry if I confused you) of the 286 segment "flatener", you can't use a flat segment addressing scheem in 286 PMode because segmetns can only be 64K is size.

Well, seeing as how the 286 is a 16-bit processor, this is unsurprising. On a 16-bit processor, using a flat memory model necessarily implies a maximum of 64K of addressible memory. Getting past that requires segments, bank-switching, or other such shenanigans.

What it sounds like what you really want is not a memory model flattener, which is easily achieved, but 32-bit addressing modes. This is actually fairly easy to implement -- catch the invalid opcode exception, and extend the processor's instruction set as desired. You can even simulate 32-bit registers if you want.

[Pype.Clicker]

1. trying to use consecutive selectors to build a 'fake' flat one will not work: the segment number after 0x28 is 0x29, which is the same selector, but with different priviledges ...

2. of what help would 32-bits 'fake' addresses (mapped to 24 bits physical addresses) be, as there's no 32-bits general register to manipulate those

Really, does 286 programming still makes sense ? If you really need 32 bits programs running on a 286, emulating the whole 386 may be necessary.

[srg]

I wonder how Windows 3.1 memory management works? (I realise that paging is activated in 386 Enhanced mode).

srg

[Dreamsmith]

I wonder how Windows 3.1 memory management works? (I realise that paging is activated in 386 Enhanced mode).

If I'm not mistaken, when not in 386 enhanced mode, it worked pretty much the same way it worked under DOS. Remember, prior to "386 enhanced mode", Windows 3.1 ran under DOS -- it was just a GUI environment for DOS. Look up the various old-style memory models (tiny, small, compact, large, and huge, IIRC) for details.