OSDev.org

Hi,

I would be very appreciative if someone could give a cursory overview of how an OS can handle memory management without a memory management unit.

Moreover, uClinux and how it manages memory without a MMU seems like black magic to me - I would be very grateful if someone could explain how it works.


thanks.

jasonc122 wrote:Moreover, uClinux and how it manages memory without a MMU seems like black magic to me - I would be very grateful if someone could explain how it works.

Having not looked at it, I'd imagine it's either some kind of JITted bytecode (which can be checked, much like Java) or just trusting all apps (which works for embedded systems, not so much for a desktop or server system)

Either way, this would also be interesting because an MMU-less OS would be easier to run as an app inside another OS. Speaking of which, User-Mode Linux might be a good idea to check out - it's designed for testing unstable Linux versions without a risk to real machines, yet without a VM so it can be integrated more easily into the host's GUI (though that's, of course, not that much of a concern for X-using Linux systems)

Right off the uClinux FAQ

Q. Does uClinux support multitasking? What limitations are imposed by not
having a MMU?

A. uClinux absolutely DOES support multi-tasking, although there are a
few things that you must keep in mind when designing programs...

1. uClinux does not implement fork(); instead it implements vfork().
This does not mean no multitasking, it simply means that the
parent blocks until the child does exec() or exit(). You can still
get full multitasking.

2. uClinux does not have autogrow stack and no brk(). You need to use
mmap() to allocate memory (which most modern code already does).
There is a compile time option to set the stack size of a program.

3. There is no memory protection. Any program can crash another
program or the kernel. This is not a problem as long as you are
aware of it, and design your code carefully.

4. Some architectures have various code size models, depending on how
position independance is achieved.

I wrote several times about that; I "grew up" on AmigaOS, which didn't support MMUs. (Later Amigas had one, but the OS was written without MMU support in mind.)

See here, that's the best I could find ad-hoc. I'm willing to answer questions that might persist.

It still has a MMU though ..it just doesnt have a virtual memory and pages. You still need malloc support and a global heap , the heap is your MMU.

Some newer OS like Singularity and SOOOS also do without virtual Memory and paging and unlike that OS they do provide full memory protection by using bytecodes /IR and only allowing code from type safe and memory safe languages eg Java , C# , Caml , Python , Java script etc

Hi,

Benk wrote:It still has a MMU though ..it just doesnt have a virtual memory and pages. You still need malloc support and a global heap , the heap is your MMU.

I believe the OP was referring to a hardware MMU, with hardware process isolation and the concept of virtual and physical memory.

Cheers,
Adam

There's no such thing as software MMU. MMU != memory manager

Benk wrote:It still has a MMU though ..it just doesnt have a virtual memory and pages. You still need malloc support and a global heap , the heap is your MMU.

The MMU is either a dedicated hardware chip (like the MC68851) or an integral part of the CPU (like the i80386). With a MMU, you have the option to map a logical address to a (different?) physical address. Without MMU, you don't have that option, but you still have to make applications, libraries, stacks and heaps to co-exist. That's what the OP was talking about.

As for the "language war", no OS that limits my choice of programming languages will ever run on my hardware.

Hello,

jasonc122 wrote:.... overview of how an OS can handle memory management without a memory management unit.

Segmentation, if you mean "MMU == Paging".
Segmentation allows a sophisticated memory-protection without paging, but all processes must use (share) the same linear (virtual) memory (4 GB on a 32 bit CPU and a little bit more on a 64 bit CPU). If you have, in addition, a Paging-Unit (MMU), you can additional use swapping to disk and runtime memory-defragmentation (defragmentation of the linear memory space that is the "heap" for the segments). The User-Mode-Processes can only access the memory in its segments, provided by the LDT.

In real live there is no modern CPU with good support of segmentation.
I try to implement my own CPU (into a FPGA) with segmentation and write an OS for it.


Greetings
Erik

Solar wrote:

Benk wrote:It still has a MMU though ..it just doesnt have a virtual memory and pages. You still need malloc support and a global heap , the heap is your MMU.

The MMU is either a dedicated hardware chip (like the MC68851) or an integral part of the CPU (like the i80386). With a MMU, you have the option to map a logical address to a (different?) physical address. Without MMU, you don't have that option, but you still have to make applications, libraries, stacks and heaps to co-exist. That's what the OP was talking about.

As for the "language war", no OS that limits my choice of programming languages will ever run on my hardware.

Anyway im pretty sure in 10 years time MMUs will disapear (Bold prediction I know) . On an Arm it takes 25% of the die in 10 years time instead of an MMU you will go from 100 -> 125 core , in addition to a 25% increase in core count you gain about 10% from TLB related issues and the power saving is even bigger since the TLB is searched /scanned in parralel. However software memory management will improve and manage swap out etc . You may even have VM using Virtual addresses which get patched.

Its hardly limiting , for the Trusted Code base you can use any language for user apps you can use any language that uses a GC and is type safe which is a pretty smart thing anyway... That just means no C user apps. You can run Java , OCaml , ObjectiveC , BItC , C++.net etc etc . The only reason you cant run C is its memory access is ( almost) unverifyable.

I can't see the MMU going away because the MMU doesn't just provide memory protection. It also greatly simplifies memory management for the operating system. It allows fragmented pieces of physical memory to be mapped to contiguous memory for the operating system to dole out to processes. Imagine how fragmented the memory in a server that has a 10 year uptime would be if it weren't for paging.

The future of computing will see more and more virtualisation. Is think this will mean the mmu stays.

- gerryg400

gerryg400 wrote:I can't see the MMU going away because the MMU doesn't just provide memory protection. It also greatly simplifies memory management for the operating system. It allows fragmented pieces of physical memory to be mapped to contiguous memory for the operating system to dole out to processes. Imagine how fragmented the memory in a server that has a 10 year uptime would be if it weren't for paging.

The future of computing will see more and more virtualisation. Is think this will mean the mmu stays.

- gerryg400

I dont think virtualization will increase much after its recent rise ( to help manage data centers better) .. barring a windows competitor and having to virtualize windows . I think the above only applies to C and C++ , all other modern runtimes use or can use a Compacting GC. Also a lot of systems are avoiding creating custom contigous page maps for processes as it will not work in the future ( due to needing a Cache and TLB flush) , start thinking 100 core and rapid context switches and you can see that path is doomed in the future thoguh has worked well in the passed.

It may not happen soon ( like high core counts) but i believe it will happen as Software can coordinate move and repatching to have minimal runtime impact , whereas the current scheme has high cost ( it may not be apparant but every memory instruction runs a parralel search on every TLB entry) .

Lastly a Software mm can page out idle code , move and repatch it etc though it does work best with GCs.
Lastly uClinux for example has an option for PIC ( ie position independent code) .

Why are some people always bashing low-level languages in favor of bloated languages ? If you're into scientific computation, you need fast code, without wanting to write a new OS. If you're into game development and do not work for Crytek, you want fast code too.

HLL are not suited for everything. It's just a fact.

99% code is written under time constraint , c code is buggy and takes a lot longer for very little performance gain.

Implement an algortihm in 2 hours i bet Ocml will be 10* faster on 10+ cores , c# will be faster and with C your still dealing with some seg fault , or looking up some threading.

I understand the time constraint argument, but what you're proposing implies dropping ALL native code (C, C++, Pascal, Pascal object, ObjectiveC, and so on...) and switch to interpreted code everywhere in user space. Because native compiled code does not include any notion of type anymore, as you probably know. For machine code, a pointer is just an unsigned integer. No more, no less.

And then about that "very little performance gain". I've heard about how small it is many times. And indeed it's true when you run complex library functions and have all libraries written in native code (again, you can't get around the need of such code ), because the instruction decoding + real-time parameter checking + garbage collection + various sandboxing + call + <insert other bloat here> overhead is small compared with the execution time of the function. As an example, Pardus linux have their package manager written in python, and except through the memory footprint you just couldn't tell. But for something that requires executing a lot of simple instructions, like physics, that overhead is too high, unless you have some NASA computer. Believe me, I've tried.

In my opinion, the best way to do fast application development is to have a smart and rigorous compiler + some powerful code generation systems. That approach was used by Delphi for rapid GUI application development, and it worked damn well (though I may be biased since I learned how to program with delphi ). But well, now developers require the computer to do more and more of their own homework at execution time. I'm fine with that as long as I can write efficient code in pascal or C(++) myself, I just hope that OS manufacturers won't *ever* make going through that bloat a requirement, as you've written above...

PS : And, by the way, C *is* type-safe, as long as you don't cast everything without a single thought... On the other hand, you mention OCaml, while some quick research tells me that in this language, you can put pretty much everything in a variable without declaring its type first... Maybe you should have a second look at what C really does *before* bashing it for the sake of bashing it...