OSDev.org

Ok I have finally caved in and wish to ask a few questions about memory managment in general and paging. It must by my lack of searching skills or something but the further I search and the more information I get the more confused I get.

Anyway...

My OS (uos) can currently boot into protected mode with no idt yet. I have a simple LibC in development and I can print to the screen (properly working printf function). I wish to set up a memory managment system to allow allocation, deallocation and reallocation of memory. I have _no_ idea beyond the basic theory behind MM of how to implement this.

Can someone tell/show me how you would implement MM (in C)?

Because paging directories can only reference up to 4mb of ram how do you allocate more than 4mb to a single task?

Thankyou in advance. This MM stuff gives me a serious headache.

check your manual again. page tables only allow for 4MB (in slices of 4KB), but a page directory handles up to 1024 tables, so up to 4GB.

http://gee.cs.oswego.edu/dl/html/malloc.html has a PD malloc() implementation that is pretty sophisticated already.

Because paging directories can only reference up to 4mb of ram how do you allocate more than 4mb to a single task?

The MMU blends physical memory (coming in 4k/4M chunks) into the virtual address space. The virtual address space is always contiguous.

So what does this mean for the purpose of implementation. That's (mostly) what I can't wrap my head around - the use of all this data to form a usefull MM engine for my OS.

Rephrased that is:
What is the easiest (but still reliable) way of handling memory and how would I impliment it?

As before thank you for any support I get. This stuff does get difficult to understand.

well, lets give it a try:

1. The Paging Mechanism makes it possible to split up the physical memory in chunks of 4k/4m. Each Entry in a Pagetable represents a chunk of 4k of memory. Each Entry in a Pagedirectory represents 4m of memory.

2. Make yourself familiar with following idea: each process owns a pagedirectory. The pagedirectory holds the memory allocations the process owns. the process sees the memory as a contiguous thing from 0 to 4 gb - virtually. In reality, chunks of physical memory are associated to its adress space. This way you can have each process have the kernel adress space mapped in.

3. As each process has it's own pagedirectory representing a different region of physical memory, *but* without the need of ... fiddling with start adresses since you can have every userprogram start at adress 0 f. ex. memory protection is given by: No process can see what is in the memory of another one. this right belongs to the kernel.

4. the memory allocator hands out/takes back chunks of memory in size of 4k/4m, depending on your configuration. It hands out memory to a process at request,and takes it back eventually - under all circumstances, when a process is killed.

5. the task of malloc is to manage the *heap*, that is a space in process adress space which is availble for dynamic memory allocation in fin grained chunks - at needs. but you have to do some bookkeeping to fease free. if necessary, it orders 4k chunks of memory from the memory allocator or returns them if not needed anymore.

Hope this helps to give you a picture of what you have to do. tim robinsons texts are fare more readable and clearer on this.

stay safe

ucosty wrote: What is the easiest (but still reliable) way of handling memory and how would I impliment it?

I would probably vote for the "hunked memory" concept of AmigaOS here, simply ignoring virtual memory completely and using position independent code throughout... but you'd probably bite yourself in the backside later on.

you'd propably bite yourself in the backside later on.

That's worth a rofl *rofl*. Never heard *that* idiom translated to english.

've always thought, they say: 'take the head between the knees and kiss the bender' - but no, I'm don't know it really.

Oh sweet gosh a'mighty, one never stops learning.

?henm ... what's it up with this 'hunked memory' concept?

ever tried Tim Robinson tutorial (should be on OS Journal or something) ?

BI lazy wrote: ?henm ... what's it up with this 'hunked memory' concept?

Amigas didn't have an MMU originally. Any library or executable comes as either position independent code or with relocation information. Binaries are loaded into physical memory by the "scatter loader", which checks physical memory for free space, puts the "hunks" of the binary (identifyiable modules) wherever there's space, and does any necessary relocation.

This results in a system where you, the programmer, don't have to worry about the actual RAM layout, ever without an MMU in the system.

And since there was no "address space" or "memory protection" involved, messaging was really fast. Just toss 'em a pointer.

Thank you for the great replies. I will use this advise. I found that I couldn't figure out how to actually impliment MM in the way Tim Robinson's tutorials showed. I just looked for some code that was easy to read (but works) and pulled that apart.

ucosty wrote: I just looked for some code that was easy to read (but works) and pulled that apart.

"Any fool can write code a machine understands. Real programmers write code that a human understand"