Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
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.
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.
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.
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.
Every good solution is obvious once you've found it.
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.
Every good solution is obvious once you've found it.
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.
