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