Pitfalls of lacking a MMU

[CrypticalCode0]

Some CPU's lack a MMU like the 80286, M68EC040 and pretties like Z80's and 6502.

Without a MMU somethings are unavailable.
This in itself doesn't mean a thing.
Some OS's did fine without one, others would be unavailable if it wasn't for a MMU.

So seriously if i wanted to write for a M68K without a MMU, or any other MMU lacking CPU where should i becarefull off?

best regards Cryptic

[NickJohnson]

Also, if you want to load multiple programs at once, you will need to support relocation or position-independent code, so they don't need to occupy the same addresses.

[Solar]

AmigaOS did very fine on the MC680x0 without MMU. The command set makes position-independent code ridiculously easy. I wrote a short article on how AmigaOS solved the library addressing problem.

On a long-running system, you will encounter the problem of memory fragmentation. Since there is no MMU to re-map scattered physical into contiguous virtual memory, that can become a problem.

On the upside, a non-MMU'ed operating system can be made really efficient. IPC is done by passing a pointer. Context switches are non-existent. (This is part of what made AmigaOS multitask so smoothly.) You sacrifice process protection, but you also gain something.

[OSwhatever]

What many don't realize is that the market for MMU-less OSes is really very big. There are plenty of systems out there that needs an operating system that runs a fixed set of software. Since the SW is already known and tested, there is (should is a better word) no need for the MMU. Features like demand paging and other paging features are often not needed. The MMU would only eat energy and slow it down.

The multicore trend is also as popular in the MMU-less world as well and SMP MMU-less operating systems is something that the market is interested in right now.

Also there are mechanisms to get protection without an MMU, perhaps not as versatile as paging but functional.

[CrypticalCode0]

SMP i am not sure how to do without a arbiter that is the MMU.
AMP is a option without a MMU IMHO.

Using PCI doesn't guaranty that programs are nice to the system, this doesn't refrain me of wanting a kernel without MMU support itself.
So OSwhatever can you give us a example or a link to such algorithms or mechanisms?

[Combuster]

Multiprocessing in any form is possible without an MMU. After all, the only difference is that programs have to use physical addresses and are not allowed to do anything wrong ever. The functionality a kernel would provide doesn't really change a lot at all, and any multithreaded algorithm would still work regardless.

[Solar]

Basically you get zero-cost context switches and IPC mechanics plus the ability to hook & patch the kernel at runtime, bundled with memory fragmentation, zero data security and catastrophic system failures.

[CrypticalCode0]

Couldn't one just maitain a list which tells start end name and entry point of each entity in memory?

[Combuster]

Not all "entities" have "Entry points"

Other than that, even a system with MMU knows what program is using what part of memory. Every malloc() implementation keeps track of which parts are used and which parts aren't. The question is: how much do space do you want to spend on metadata for what granularity of allocations.

[CrypticalCode0]

Combuster your right but i used the term entity here on purpose instead of program since it can also refer to a library.(or a sub routine for that matter)
Like you yourself said it's a matter of how detailed you want to have it.

a MMU is limited to a minimal page size and limited to a maximal page size your limited to allocating pages.
I allocate address space byte by byte.

anyhow having some reference point is vital no matter what you program, if i am planning to implement PIC with or without a MMU.

[Tosi]

Sorry if I'm wrong since I haven't posted in a long time and haven't been into OSdev recently either, but even without an MMU, most things can be done and some protection can be implemented.

For instance, in the x86 system I don't consider segmentation an "MMU" because it has been around since almost the beginning. With the introduction of protected mode and a flat address space, segmentation changed purpose from extending memory beyond 65536 bytes to allowing a basic form of protection; using segmentation, each running process could have its own segment that determines which addresses can be read and written from, and also maps physical addresses, allowing multiple processes at different physical addresses to run at the same virtual one in a given segment.

If you do consider the protected mode segmentation to be a form of MMU, then without it there is very little security indeed. However, most things like memory allocation can be done, just without a layer between logical/virtual memory and physical memory. The main caveat is that every process has to agree to not try anything funny and stick to its own address space. Kernel debugging can be difficult to since if the kernel writes to an invalid address (e.g., a NULL pointer), it won't throw an exception automatically. However, it may be able to spot malicious programs, at least ones that try and write to random spots in memory. In a preemptive multitasking system, the kernel could check some reserved "special" memory locations to see if the values there have been changed. This will incur a small overhead depending on how its implemented, and even if a malicious attempt is detected, it may be difficult to determine which program is being naughty. The easiest way would be to check which programs have had some time running on the processor since the memory was last checked; if there's only one, that's probably the culprit (unless some driver or kernel code is malfunctioning!). If all else fails, just blue screen, à la early protected mode Windows without full memory protection.

Combuster your right but i used the term entity here on purpose instead of program since it can also refer to a library.(or a sub routine for that matter)
Like you yourself said it's a matter of how detailed you want to have it.

a MMU is limited to a minimal page size and limited to a maximal page size your limited to allocating pages.
I allocate address space byte by byte.

anyhow having some reference point is vital no matter what you program, if i am planning to implement PIC with or without a MMU.

A library or sub-routine will always be running as part of some process, or possibly in driver or kernel code if those aren't considered processes on some OSes. And not all hardware memory-managers use paging, although it is one of the most common forms. You can still implement an allocator on top of a fixed page size that can allocate arbitrary sizes however.

[CrypticalCode0]

Tosi your right you could see segmentation as a form of protection, i wouldn't call it a MMU thing though that is stretching it.

This is off-topic
because segmentation is architecture dependent I cannot use it for protecting code nor data.

As for viruses i would have to say security through obscurity.
Besides that i am a type of guy that has a 'use it or lose it' mentality and hence i would likely go for a very minimalistic microkernel.(perhaps i should create a thread for it)

Back to the topic of this thread
You could use segmentation for it but then you don't have portable code.
Besides that it's slower then using a flat address space.
Perhaps i should have started of about what sort of API would make a MMU redundant, well it's too late now. :/

[Combuster]

Tosi your right you could see segmentation as a form of protection, i wouldn't call it a MMU thing though that is stretching it.

Segmentation has always been a way to manage memory. While it only served to get access to more than 64k of memory on 8086s, 286 segmentation was capable of more security than 386 paging (And it still provides capabilities paging can not provide. Try for an exercise to look up why virtualisation does not require processor extensions in 32-bit mode)

A memory management unit (MMU), sometimes called paged memory management unit (PMMU), is a computer hardware component responsible for handling accesses to memory requested by the CPU. Its functions include translation of virtual addresses to physical addresses (i.e., virtual memory management), memory protection, cache control, bus arbitration and in simpler computer architectures (especially 8-bit systems) bank switching.

Therefore, by definition, all x86s have an MMU, and segmentation is always part of it.

[Love4Boobies]

A couple of mechanisms that allow MMU-like protection on MMU-less systems come to mind: software guards (they're terribly slow but they provide compatibility with legacy software, if that's a requirement) and managed code (performance depends on the implementation but it's usually better for some things, such as IPC, and worse for some, such as using... arrays).

[ACcurrent]

and managed code (performance depends on the implementation but it's usually better for some things, such as IPC, and worse for some, such as using... arrays).

Well what I have done for my OS (and the reason its taking forever) is create an AOT interpreter which "installs" the app from a bytecode. The generated code is safely guarded through the compiler and every time you launch the app the executable code is verified and launched. NO MMU!