Updates

Here's an update on my recent works. Our story left off at enhancing the page allocator and pager code that I've written for the SharpOS kernel. Since then I've spent my time (what time I have between other obligations) doing a number of things:

Extracting ADC from PageAllocator

I've started to work out the logistics for an ADC module. Many things remain unclear. It's obvious that in an ideal situation we'd want each ADC layer to be placed in individual DLLs which can be AOT-compiled-in when we build the kernel. This allows us to only have to build the kernel once for all platforms supported with ADC (:-D). However, at this point in the game the AOT can't do multi-DLL compilation (but I think only a small change is required). Right now I've got two ADCs, SharpOS.ADC.X86 and SharpOS.ADC.Generic. I've posted X86 in my sandbox folder, but the usefulness of Generic (which is really just a 'null' implementation) is shaky.

AOT branch

I also started my own AOT branch which has some nice trivial changes for things like option support and output verbosity. The most notable thing I did was write a few scripts and embed them as resources so the AOT would be able to generate a DOS floppy image for testing, directly after compilation (and automatic :-D). This should speed up the testing process a bit, as creating the image files for testing is a real pain on both Windows and Linux.

Enhancing the Page Allocator

Very much aligned with the fact that the control bitmap technique was wholly unsatisfactory, last night I changed the page allocator I'm working on to use the free page stack technique. I even wrote the code to allocate a range of contiguous physical pages. I still must finish paging and the basic memory mapping API.

Building the Memory Manager

I've started work on the memory manager implementation for SharpOS. Mostly this is because it hasn't been done yet and I will need the functionality to test any of the other code (SharpOS.EIC and SharpOS.Runtime) using the SharpOS AOT compiler.

Using various internet resources I have hacked together what is a mega-basic page allocator. It uses the provided Multiboot information to determine the amount of RAM, and the offset/size of the kernel must be passed to MemoryManager.Init(). Using this information, it sets up a bitmap for control information on the first page past the end of the kernel, and reserves the pages below 0x100000 as well as the pages occupied by the kernel. The only thing left to implement for a basic page allocator is the Alloc/Dealloc, which is a matter of binary search.

The allocator also handles setting up 2-level paging and enabling it, but right now it does not relocate anything--so physical == virtual. I'd like to put the kernel in the higher half, but that requires modifying the segment base pointer so that we don't have to relocate pointers (would be tedious). I think I need the AOT's help to manipulate the segment base pointer at the right time (compile-time?).

Of course, the bitmap is not an ideal method of memory management. The bitmap search will be slow once lots of memory is allocated, and I'm looking into various ways of improving the performance. One method I've seen is to use another control bitmap for 'superpages' which represent large blocks of pages. Another method is to use a stack of free pages and just pop and push pages to it for allocation. This is a much faster way of allocating, but apparently gets difficult when allocating contiguous pages. I believe it is the method used by Linux and Windows NT though, which lends credence to the concept.

More later!

SharpOS Foundation

I am currently working on a foundation layer for the SharpOS kernel in the form of a runtime and utility library. The utility library is going to turn out kind of like a C library for C#, providing a String object, an Array object, various linked lists, etc. The runtime has now merged with SharpGC in terms of in what assembly it is (SharpOS.Runtime.dll), and the delegate use has been squelched because I don't think we're going to have an easy time converting delegates to function pointers and back again. Instead, the GC takes a reference to a Runtime* object when it is created and it calls methods on that runtime when it needs to do object-walking and runtime finalization. Oh, I've also moved the Heap* object to the SharpOS.Memory library along with the MemoryManager prototype. This makes more sense in terms of what the Heap does and the namespace it's been occuping (SharpOS.Memory as opposed to SharpOS.Runtime).

I am now working on tests for the EIC objects, then I will look to expanding the set to a few more utilities, and perhaps integrating bmarkham's Math object. Lots to do in SharpOS land.