OSDev.org

1. What does it mean by 'A stack expands downwards'? Can somebody explain, using concrete memory addresses to me?

int *stack;
void push(int a) {
  *stack++ = a;
}
int pop() {
  return *--stack;
}

int *stack;
void push(int a) {
  *stack-- = a;
}
int pop() {
  return *++stack;
}

2. How is physical memory management done? I think it's something along the lines of simply keeping track of what you can and cannot use, splitting up that memory and passing pointers around?

3. I mostly get paging… *mostly*. I get the part where there's an address in memory, and you apply these flags to it… Like

Problem: As I understand, pmm_alloc_page() returns a pointer to somewhere in memory. Is this what is going on: pd is somewhere in memory, and in the 1022'th index of that bit of memory, the pointer to the allocated memory is flagged with PAGE_PRESENT and PAGE_WRITE?

How, then, is paged memory managed?

4. What is the heap? (yes, I am clueless.) From what I know, malloc() can use physical memory allocation, however it has no way to be free()'ed. (right?) Whereas once a heap is setup, both malloc() and free() can be used to manage chunks of memory?

Furthermore, most of it is described in Intel Developer Manuals, ARM manuals or any manual for your target platform, so your questions from 1. to 4. qualify as RTFM.

Griwes wrote:Maybe not, but still, after few seconds of typing a query into Google, you can get information about it written in "nicer" way than in manuals...

requimrar wrote:1. What does it mean by 'A stack expands downwards'? Can somebody explain, using concrete memory addresses to me?

JamesM wrote:weren't stupid

VolTeK wrote:

requimrar wrote:1. What does it mean by 'A stack expands downwards'? Can somebody explain, using concrete memory addresses to me?

JamesM wrote:weren't stupid

Assembler is required isn't it?

VolTeK wrote:

requimrar wrote:1. What does it mean by 'A stack expands downwards'? Can somebody explain, using concrete memory addresses to me?

JamesM wrote:weren't stupid

Assembler is required isn't it?

JamesM wrote:
These code fragments do exactly the same job, but in the first the stack expands upwards - that is, as we push items onto the stack the stack pointer (int *stack) gets higher. The second expands downwards, so as you push items to the stack, the stack pointer gets lower.

As with most problems, there are many ways to implement a physical memory manager (stack, bitmap, buddy etc) - each have a set of disadvantages and advantages. The problem of physical memory management itself however is trivially simple: you have a set of "pages" that are free, and a set of pages that are used. Expose an interface such that a user can request a page (that must be free, now mark as used) and return pages (were used, now free).

That is what the function "pmm_alloc_page()" in your code snippet does. It just returns the address of the start of a page in physical memory that was free. It does *not* guarantee that page is accessible (if paging is enabled, it may need to be mapped into the virtual address space before it can be accessed).

pmm_alloc_page() requests a free physical page from the physical memory manager. It returns the address of a free page in physical memory. That line is saying, in English: "Request a new physical page. OR its address with the "present" and "write-enable" flags, then store that computed value into the 1022'd index of "pd", which is an array of 32-bit integers".

This works, because at the time when that code is run, paging is actually disabled. So physical addresses == virtual addresses. That's why you can write to 'pd' just through a pointer to what would normally be inaccessible physical memory.

I don't know exactly what you're asking here. A physical memory manager manages the availability of physical pages. A virtual memory manager maps these pages into the virtual address space. You may have another manager to partition up the available virtual address space.

A heap sits atop the virtual and physical memory managers. It is given an area of virtual address space to operate in, and will allocate physical pages (using the PMM) to fill that space, mapping them in using the VMM.

It will then use some algorithm to carve that space up into manageable,trackable chunks to give back to callers of "kmalloc" and returning them with "free".

requimrar wrote:So in visual terms… It's kinda like a floating stack of blocks that can magically hold on to things attached to it's bottom?

requimrar wrote:

JamesM wrote:
These code fragments do exactly the same job, but in the first the stack expands upwards - that is, as we push items onto the stack the stack pointer (int *stack) gets higher. The second expands downwards, so as you push items to the stack, the stack pointer gets lower.

So in visual terms… It's kinda like a floating stack of blocks that can magically hold on to things attached to it's bottom?

As with most problems, there are many ways to implement a physical memory manager (stack, bitmap, buddy etc) - each have a set of disadvantages and advantages. The problem of physical memory management itself however is trivially simple: you have a set of "pages" that are free, and a set of pages that are used. Expose an interface such that a user can request a page (that must be free, now mark as used) and return pages (were used, now free).

That is what the function "pmm_alloc_page()" in your code snippet does. It just returns the address of the start of a page in physical memory that was free. It does *not* guarantee that page is accessible (if paging is enabled, it may need to be mapped into the virtual address space before it can be accessed).

*my* code snippet…? I think you mean *your* code snippet. Unless of course you didn't actually write it.
But yes, now I get it.

pmm_alloc_page() requests a free physical page from the physical memory manager. It returns the address of a free page in physical memory. That line is saying, in English: "Request a new physical page. OR its address with the "present" and "write-enable" flags, then store that computed value into the 1022'd index of "pd", which is an array of 32-bit integers".

This works, because at the time when that code is run, paging is actually disabled. So physical addresses == virtual addresses. That's why you can write to 'pd' just through a pointer to what would normally be inaccessible physical memory.

So because paging is disabled, all the addresses are physical and you can just access it through pointers?

I don't know exactly what you're asking here. A physical memory manager manages the availability of physical pages. A virtual memory manager maps these pages into the virtual address space. You may have another manager to partition up the available virtual address space.

Well I guess it's just a PMM with virtual pages?

A heap sits atop the virtual and physical memory managers. It is given an area of virtual address space to operate in, and will allocate physical pages (using the PMM) to fill that space, mapping them in using the VMM.

It will then use some algorithm to carve that space up into manageable,trackable chunks to give back to callers of "kmalloc" and returning them with "free".

What's uh… 'some algorithm'?

Also, thanks for defending me. (:

- Remember to set up the higher half addressing!

Set up Long Mode readying stuff (PAE, *PML4* etc)

Blacklight wrote:

requimrar wrote:So in visual terms… It's kinda like a floating stack of blocks that can magically hold on to things attached to it's bottom?

Imagine you have some blocks. You take a red block and put it down. You put a green block on top of it, then a blue block on top of that one. Now, if you take any block off the top, everything's fine. But if you take any blocks out of the middle or bottom, the whole thing will fall over. So, if you want to take the green block back, you need to first take off the blue one, then the green one. You can then put the blue one back on.