64 Bit D Kernel

[Alexander Panek]

Jarrett Billingsley wrote:
> "Alexander Panek" <a.panek at brainsware.org> wrote in message 
> news:ffk3sd$2is7$1 at digitalmars.com...
>> Brian Madden wrote:
>>> As of right now our code is sort of all over the place, and fairly 
>>> undocumented, but we're mostly groping in the dark right now.  If anyone 
>>> has questions or comments, feel free to voice them.
>> I hope there'll be some more documentation, soon. I don't know how you 
>> guys communicate during development, but e.g. a public mailing 
>> list/newsgroup/forum would be tremendously cool to track down your 
>> design/implementation decisions and such (doesn't really make sense if 
>> you're sitting next to each other, communicating vocally, of course).
> 
> Usually we communicate with our mouths.  Texts, IMing, and vulgar hand 
> signals are our other main channels of communication.  ;)

That's great! Be sure to keep a Stik around.

>> Ad comments..mhm.. I got a few questions, if you don't mind :)
>>
>> - Did you guys try to make the build process work with DSSS entirely?
> 
> We've got a pretty involved build process, and not many files yet.  I don't 
> think DSSS would be of much use at least until a later stage.

As of now, you seem to use a Makefile; building with DSSS would be more 
interesting in terms of "proof of concept", etc. I tend to try to keep a 
project sticking to its languages'(or language's) tools, which would be 
DSSS in case of D, respectively Make in case of C or assembly (though 
you can do that one file with DSSS, too :P).

>> - Where there approaches to get rid of assembly and/or C?
> 
> There are no C files left.  I think the only (non-inline) assembly left is 
> boot.S, which is called by GRUB and sets up the stack, initial GDT, and 
> initial page table and makes the jump to 64-bit mode.  After that, it's all 
> D with some inline assembly here and there (thank you GDC's extended ASM 
> syntax).

Right..you jump into the cold water (64bit) right there, missed that.

> I have no idea if we plan on moving this to any other architecture.

Hehe, maybe you should at least /plan/ to, so you have a code base that 
allows it....

>> - Why exokernel? Why not micro?
 >
> I defer to James for that argument :S

...but apparently James knows more about this in particular. :)

Personally, I am planning on splitting up my kernel into a completely 
platform dependant (the nucleus), and a mostly independant (the actual 
kernel) part. Basically, the nucleus implements a specific interface for 
all sorts of memory operations (allocating, sharing, moving, as well as 
paging and other rather platform specific [from an implementation point 
of view] things) and maybe additionally the base of IPC, as long as the 
platform has some support for it, that might speed up things.

The rest should be implemented "generic" enough to keep the code base 
platform independent. If this independency isn't feasable, this 
particular piece of code should be put into a module, rather than 
"polluting" the kernel package(s).

Best regards,
Alex