LtG wrote:
Few separate things:
- Pitfall was asking why 1GiB blank blocks were left in the address space, I have no idea, but possibly some implementations (MoBo impl) use it for more efficient routing of memory. Though that's just a guess, there's likely some firmware/hardware related reason. Might also be some legacy reason related to FW/HW.
- Using bitmaps for "sparse" address space (sparse meaning there's empty holes) has a few potential solutions:
--- Just create large enough bitmap to cover the entire range, wasting bits for all the range not used. Assuming 4KiB pages are represented by single bit in the bitmap and assuming 16GiB system with each GiB having an extra 1GiB empty space in between means you'd need to have a bitmap for 32GiB of address space, even though only 16GiB of RAM exists. If I did my math correctly that means 8MiB bitmap, not a huge deal. Note, I think a stack is easier, better, faster, wastes less space, etc.. I can't really think of good reasons to use bitmaps. From this you can probably guess that my suggestion to you is to use a stack, as a consequence whether the memory is totally fragmented and in pieces becomes irrelevant to you and you don't have to care.
--- Alternatively you could create multiple bitmaps, recording the start address of each, this is more complicated and given that unless you have a specific reason to use bitmaps I seriously would recommend against the extra complexity.
- "aka you assumed it was contiguous", don't assume. Remember, back in the day certain things were at certain "known" (aka special/magic) locations, those locations still need to exist, thus they become similar to holes in the memory in the sense that they don't go to the RAM.
- Are you sure your current memory map print from your PC (which still looks weird) is using proper uint64_t for the first two columns (start and length IIRC)? They seemed to have the first part (most significant) cut off, yet the last column seemed to be able to report over 32-bit values.
- You complained about "not including anything you haven't written", do you manually write your code in asm? If not did you write your own compiler? If not, then you are already using code you didn't write. The basic headers are _part_ of the compiler, you should almost never mess with them. If they produce invalid code (which I presume is your reason for not including them) then you shouldn't trust the compiler either. STL and the standard libraries are a slightly different matter. So check the cross-compiler wiki article and include the stuff it tells you to, everything else is up to you, but if you mess with the bare minimums you'll just keep shooting yourself in the foot. There's some things that are trivial, but even many of the trivial things are anything but trivial, there's almost always some tiny minutia you have to get right and trying to do that yourself isn't really a good idea _with_ osdev.
- As for why the physical memory map is not contiguous, there's no need. Nobody needs it to be. And remember, it's not all _RAM_, there's memory mapped I/O there too (aka peripheral devices), etc. And the framebuffer for video is there too, so it's just something you have to live with, with virtual memory it really doesn't matter.
Finally, it's important that you fully understand that the following four concepts are complete different:
- PAS = Physical Address Space
- PM = Physical Memory
- VAS = Virtual Address Space
- VM = Virtual Memory
With VAS and VM, the entire 4GiB (for 32-bit prot mode) VAS always exists, whether something is mapped there as backing store is completely different, but if there is, then that's called Virtual Memory.
It's the same thing with the PAS and PM, they physical address space always exists (to varying degrees, AFAIK nobody has implemented a MoBo with all 64-bit PAS, because nobody "wants" it), whether something is mapped, and if something is mapped it might not be RAM. So the PAS is not memory, it's just address space, some address might go to memory, some might go to devices, some somewhere else. You're not allowed to guess, anymore than apps are allowed to guess VAS, the OS terminates such apps.
So start thinking about them as address spaces, both physical and virtual, and that memory is just one subtype that might be mapped to particular location in the address space.
I've chosen to use a bitmap because of its simplicity. I understand it very well and it makes sense. I don't particularity fancy anything else. It just makes a lot of sense in my head.
I can go as far as taking an existing standard types header and remodeling/reshaping it to fit my style of coding. Every little space/tab and pixel matters, remember?
I wasn't talking about the IDE or tools used to build the OS, but rather about the central code itself, doesn't really matter, not thread specific.
Looks like I lived in a perfect world where everything was contiguous. Time to break that illusion. PAS != PM
VAS for the rescue. Will try to make that one as standardized and contiguous as possible. It is easier when you know what every single address of your OS contains. That is why is like contentiousness, easy to "head book-keep".
Finally after some hardcore Wiki consulting and realizing how unnecessary complicated my code was. Here is some generally large progress:
Attachment:
NewMemoryMap.png [ 10.51 KiB | Viewed 3246 times ]
I purpose I can safely ignore the last chunk?