You can certainly do that, but it may not save you as much complexity as you think.

One of the main benefits of virtual memory is that it keeps different processes from needing to know which parts of memory other processes are using.

On a system with virtual memory, one of the main jobs of the MMU is to give each process the illusion that the whole machine is theirs. As an example, if you have three programs you want to run on your OS, each can be compiled to start at memory address 0 — and none of them has to be changed if you want to run all three at the same time. You are right, however, that this adds complexity to the kernel.

If you decide to save this complexity by making it the program’s job to not use the same addresses used by other programs, there are two main ways you can go:

• One option is to make each program use a different range of memory — if program1 only uses addresses 0 .. 8191, and program2 only uses addresses 8192 .. 16383, then (barring a bug), they won’t interfere with each other, but — and this is a big deal — you need to plan in advance what range of memory each program will use, so you need to know beforehand all the programs which will run on your OS. This may be workable for an embedded system (and may be the only choice there), but is obviously a show stopper for an OS which you hope other people will build software for. Historically, a method like this was also used for some early shared library implementations, and proved very hard to get right.

• Another option is to compile each program using what’s called position independent code — code where no absolute addresses are compiled into the program, and all access to variables and code within the program is done by first checking a register (possibly the program counter) for a value pointing to where the program actually is in memory. This allows multiple programs to coexist, but requires the compiler and linker to do more work to make the program work this way, requires the operating system to do more work when loading each program, and has a cost in performance every time access to a variable or function has to be computed using this method. Historically, some operating systems, including classic MacOS before version 7.1, have taken this approach, and something like this is still used in modern shared library implementations.

So, you can move the complexity from the kernel to each running program, or from the kernel to your record-keeping of which program gets loaded where — but you can’t get rid of it altogether.

It’s fairly common for embedded kernels not to use virtual memory, because protecting processes’ memory spaces from each other isn’t as important, and you generally have a relatively small amount of memory. In that case, the MMU is primarily used for protecting appropriate parts of the address space as read only, so you get segfaults when you want them.

With 32GB of RAM, though, you’d require a 64-bit machine to address it all natively, or some other paging scheme. Also, you still have to understand the MMU in order to initialize it properly, so it might not save you that much effort. Unless you’re building a dedicated machine that only runs a handful of processes, I would highly recommend biting the bullet and implementing virtual memory.

An MMU plays two major roles: it translates virtual addresses into physical addresses, and it allows the possibility of trapping (also known as faulting and various other names), i.e. executing code (in the kernel context) when a process dereferences certain virtual addresses.

There is a third related capability, that of having different mappings and different traps for different processes. This is a consequence of executing code to change MMU settings during a context switch. This doesn’t require anything special about the MMU (but most processor designs have features in the MMU to make this more efficient).

Some processors (typically high-end microcontrollers, such as the ARM Cortex-M3) do not support translations but nonetheless support trapping: they have a memory protection unit (MPU). An MPU allows the kernel to prevent certain addresses from being accessed. Thus you can enforce memory separation between processes at runtime with only an MPU, you don’t need an MMU.

If you have an MMU, you can use it as an MPU. It’s up to you to design your kernel such that every virtual address is either always mapped to the corresponding physical address or unmapped. (An unmapped address triggers a trap.)

There is a version of the Linux kernel that supports processors with an MPU but no MMU: µClinux. The code is integrated in the Linux source tree under nommu architectures. The lack of an MMU brings some limitations, in particular the impossibility of implementing fork.

An important thing that you give up if you have no virtual memory is the ability to load every program in the same address space. This makes it considerably easier to compile programs. For example, with virtual memory, you can choose to always load the code of a program at a certain predefined address, store global variables at a predefined address, etc. If every process is stored at a different address, you need to generate position-independent code all the time.

Another limitation of having no virtual memory is that memory management becomes more difficult, because of fragmentation. Suppose you have four consecutive physical memory pages of 4kB each, numbered 0,1,2,3, and you first allocate four page-sized objects, one in each page; then you free the objects in pages 1 and 3. With virtual memory, you can allocate an 8kB object made of pages 1 and 3 by mapping them at consecutive addresses. With a direct physical mapping, page 1 is lost until you need a single-page object or the surrounding objects are freed.

If you want, you can use your processor without activating its MMU. All processors boot with the MMU turned off, because you can’t do anything useful until the MMU tables have been initialized to something sensible. With no MMU, you can’t enforce any isolation between processes. You also can’t swap, or have memory-mapped files.

With address 0 mapped, take care if you program in C or most other languages. There are a lot of runtime environments and non-fully-portable C code that assume that an address of all-bits-zero is the NULL pointer, which does not point to any object.

Depending on the architecture, there may be no way to access some hardware without mapping it into memory. This requires having the MMU up and going. You can still pretty much ignore the MMU by mapping the physical RAM from address 0, mapping devices above the last RAM address, and never changing the MMU mapping.

All in all, by eschewing virtual memory, you’re simplifying some parts of the kernel, but making it a lot more difficult to write programs that do anything useful. There’s a reason why all high-end processors have an MMU: it’s difficult to do anything sophisticated without it. MMU management is not the most difficult part of writing a kernel if you keep it simple; if you find it “mind-boggling”, you have a lot to learn about low-level programming. Writing a kernel with MMU management would be a very good learning exercise.

Since you don’t take Karl’s answer, I will try to answer your question: with no virtual memory, a useful MMU will be based on memory segmentation, pretty much like what the DOS did in the old (good) days – you allocate memory in segments and addresses are always local to the corresponding segments. Another approach is to go with no MMU at all (for embedded systems) – all processes uses a pre-allocated address schema and you will quickly find out 32G is not big enough.

Again, as Karl suggested, you should bite the bullet.

Added more detail to Robert’s comment

For a system that needs to dynamically load and unload modules, the free physical memory is always dynamic. To a module that assumes direct physical memory access, there is a hard way to locate it’s data and code: when the module is loaded, scan the machine code and rewrite all pointers to the allocated addresses. I have not read anything in detail about this technique but it just sounds pain to me (while windows does this for dlls). An easier way to address this is to use local addresses to segments – the location of a segment may change but the address relative to its beginning never changes.

Whether segmentation is supported in modern computer is not relavent, it’s just an memory management solution that is easy to implement.

You certainly don’t have to, a lot of small systems didn’t. Early versions of Windows, PalmOS and Apple’s pre-OS X systems used “handles”, which were basically indexes into a table of pointers to memory regions. The idea was that programs would do all their memory referencing via the handles, giving the system the ability to move the memory regions as needed (to prevent fragmentation). It’s hard to prevent memory corruption with such a scheme, and it can lead to strange bugs if you create a pointer to a region that gets relocated.

I believe IBM’s OS/MFT (going wayyy back) simply partitioned memory into fixed-size regions (defined at ‘system generation’ time), then loaded a single program into each region. Each program was only supposed to use the memory in its region, so all programs had to know their memory requirements. Depending on the tasks you’ll be running, maybe something simple like this could work.