Kernel in D

Qox via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat May 31 15:54:47 PDT 2014


You should definitly use templating and CTFE for your advantage.
For example you could use the (compile time) component based 
design to design (heap) allocators after a at cmpile time known 
configuration. The possibilities of templating and compile time 
code gen are enormous.

Instead of using "real" OOP classes you should use the object 
bound functions (you have functions which take as a first 
argument the struct or a ref of a struct, just look it up in the 
documentation for the functions).
This allows to use OOP without writing a GC.

Furthermore, all kind of array ops need GC.

If you want exception handling it could be a small problem. Even 
a "simple" scope expression

> scope(exit) foo();

uses exception handling in the background.
It could be possible to diassemble the *.obj/*.o file, change all 
entries which use __except_list to something else.
Basically you need to rewrite *** [fs: __except_list] to 
something else which doesn't use fs, maybe you can get away with 
using a global scratch memory, i've not done any experiments tho.

Inovation with D is allways a good thing :)

---

For the building of the kernel i used gdc, together with a ld 
linkscript and some other magic (a python script which grabs some 
stuff from a disambled file or modified something, dunno). Today 
gdc is outdated, so i would choose ldc or dmd (ldc for better 
speed, but its not that important in the beginning).


More information about the Digitalmars-d-learn mailing list