www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Kernel Development

reply Jesse Robinson <robgunnatkin gmail.com> writes:
Just for fun and as a serious learning exercise, I'm developing a hobby kernel
of sorts (L4 microkernel inspired) and since it's my play project I was
thinking of using D to implement it. I know it'll have to be written in a
strict subset of D, as most of the runtime will need to be stripped out anyway.
I've done some basic research, stumbled upon XOMB OS (a small exokernel project
written in D) but wanted some thoughts from people who may have much more
insight into the internals of D. So a few questions:

What exactly are the language features I can use at such a lower level? I know
OOP stuff is out (or is it?), dynamic arrays, GC, lazy functions, etcetera. So
that leaves structs, CTFE, contract programming, mixins, templates, AST macros,
basically any compile time features, correct? I'm sure there are a few others
I'm missing.

I've been lurking for awhile, and last time I checked there were three
different compilers. LDC looks to be the most promising. What are peoples'
thoughts / experiences with the latest version of LDC?

How large is D2's runtime? Is it even worth the time and effort to strip down a
custom runtime for kernel use in the first place? In general things need to be
fairly lean, so executable size is a concern.

Oh, and thanks in advance!

-Jesse
Nov 11 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
If you don't use things that rely on the gc, the runtime support needed 
by D2 is very minimal. You'd need to avoid:

. resizing arrays
. associative arrays
. closures
. of course, any use of new
. array concatenation

and the rest is pretty good to go.
Nov 11 2009
parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 11 Nov 2009 20:02:16 -0800, Walter Bright wrote:


 If you don't use things that rely on the gc, the runtime support needed
 by D2 is very minimal. You'd need to avoid:
 
 . resizing arrays
 . associative arrays
 . closures
 . of course, any use of new
 . array concatenation
 
 and the rest is pretty good to go.


Could I get a clarification here? You say not to use 'new' but Sean Kelly 
is saying that it is still usable. I of course place greater weight on 
your word. If 'new' is not an option does that take using objects out of 
the equation?

Just collecting details for: http://www.prowiki.org/wiki4d/wiki.cgi?
GarbageCollector
Nov 11 2009
parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Jesse Phillips wrote:

 On Wed, 11 Nov 2009 20:02:16 -0800, Walter Bright wrote:
 

 If you don't use things that rely on the gc, the runtime support needed
 by D2 is very minimal. You'd need to avoid:

 . resizing arrays
 . associative arrays
 . closures
 . of course, any use of new
 . array concatenation

 and the rest is pretty good to go.


 
 Could I get a clarification here? You say not to use 'new' but Sean Kelly 
 is saying that it is still usable. I of course place greater weight on 
 your word. If 'new' is not an option does that take using objects out of 
 the equation?
 
 Just collecting details for: http://www.prowiki.org/wiki4d/wiki.cgi?
 GarbageCollector



I think new should work fine if you explicitly call delete. sean: If 
that is not really the case then it should be?
Nov 11 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
Tim Matthews Wrote:


 Jesse Phillips wrote:

 On Wed, 11 Nov 2009 20:02:16 -0800, Walter Bright wrote:
 

 If you don't use things that rely on the gc, the runtime support needed
 by D2 is very minimal. You'd need to avoid:

 . resizing arrays
 . associative arrays
 . closures
 . of course, any use of new
 . array concatenation

 and the rest is pretty good to go.


 
 Could I get a clarification here? You say not to use 'new' but Sean Kelly 
 is saying that it is still usable. I of course place greater weight on 
 your word. If 'new' is not an option does that take using objects out of 
 the equation?
 
 Just collecting details for: http://www.prowiki.org/wiki4d/wiki.cgi?
 GarbageCollector


 
 
 I think new should work fine if you explicitly call delete. sean: If 
 that is not really the case then it should be?


Right.  I think Walter meant that "new" would use the GC for allocation, so
stubbing out gc_malloc() entirely will break "new".  I suggested replacing the
GC with a non-collecting allocator, something like the malloc/free-based stub
in Druntime.  Using this, "new" will work but you'll have to call "delete" to
release the memory.
Nov 11 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

You'd need to avoid:


. resizing arrays
. associative arrays
. closures
. of course, any use of new
. array concatenation<


Sean Kelly:

 Right.  I think Walter meant that "new" would use the GC for allocation, so
stubbing out gc_malloc() entirely will break "new".  I suggested replacing the
GC with a non-collecting allocator, something like the malloc/free-based stub
in Druntime.  Using this, "new" will work but you'll have to call "delete" to
release the memory.<


It can be useful to have a single compilation flag that replaces the GC with
the stub, removes the larger GC from the binary, and totally disallows the
usage of array resizes, array concatenations, associative arrays and closures.

Bye,
bearophile
Nov 12 2009
parent reply Jesse Robinson <robgunnatkin gmail.com> writes:
bearophile Wrote:


 Walter Bright:

You'd need to avoid:


 . resizing arrays
 . associative arrays
 . closures
 . of course, any use of new
 . array concatenation<
 
 
 Sean Kelly:

 Right.  I think Walter meant that "new" would use the GC for allocation, so
stubbing out gc_malloc() entirely will break "new".  I suggested replacing the
GC with a non-collecting allocator, something like the malloc/free-based stub
in Druntime.  Using this, "new" will work but you'll have to call "delete" to
release the memory.<


 
 It can be useful to have a single compilation flag that replaces the GC with
the stub, removes the larger GC from the binary, and totally disallows the
usage of array resizes, array concatenations, associative arrays and closures.
 
 Bye,
 bearophile


Such as flag would be very useful in cases like this. Basically, have a switch
to turn D in a leaner language for OS / system development.
Nov 12 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Jesse Robinson, el 12 de noviembre a las 21:02 me escribiste:

 Sean Kelly:

 Right.  I think Walter meant that "new" would use the GC for allocation, so
stubbing out gc_malloc() entirely will break "new".  I suggested replacing the
GC with a non-collecting allocator, something like the malloc/free-based stub
in Druntime.  Using this, "new" will work but you'll have to call "delete" to
release the memory.<


 
 It can be useful to have a single compilation flag that replaces the GC with
the stub, removes the larger GC from the binary, and totally disallows the
usage of array resizes, array concatenations, associative arrays and closures.
 
 Bye,
 bearophile


 
 Such as flag would be very useful in cases like this. Basically, have a switch
to turn D in a leaner language for OS / system development.


I think LDC already have this flag, it doesn't change the GC
implementation and I haven't tested it either though :)

-noruntime   - Do not allow code that generates implicit runtime calls

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Just because you're paranoid, don't mean they're not after you.
Nov 12 2009
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
I suggest reading http://dsource.org/projects/druntime/wiki/RuntimeSpec.  If
you want to get rid of GC, multithreading, etc, it's pretty easy to stub out
portions of the runtime and recompile.  In fact, there's a "stub" GC that just
calls malloc and free, which can be plugged in as-is.  Losing GC means you'll
leak if you use AAs, dynamic array resizing and concatenation, and probably one
or two other things, but "new" will still work, etc.
Nov 11 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 11, 2009 at 7:32 PM, Jesse Robinson <robgunnatkin gmail.com> wr=
ote:


 What exactly are the language features I can use at such a lower level? I=


 know OOP stuff is out (or is it?), dynamic arrays, GC, lazy functions, etc=
etera. So that leaves structs, CTFE, contract programming, mixins, template=
s, AST macros, basically any compile time features, correct? I'm sure there=
 are a few others I'm missing.

Just FYI, there are no AST macros in D at the moment.  The "macro"
keyword is reserved, but it doesn't yet do anything.

--bb
Nov 12 2009
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 11/12/09 04:32, Jesse Robinson wrote:

 Just for fun and as a serious learning exercise, I'm developing a hobby kernel
of sorts (L4 microkernel inspired) and since it's my play project I was
thinking of using D to implement it. I know it'll have to be written in a
strict subset of D, as most of the runtime will need to be stripped out anyway.
I've done some basic research, stumbled upon XOMB OS (a small exokernel project
written in D) but wanted some thoughts from people who may have much more
insight into the internals of D. So a few questions:

 What exactly are the language features I can use at such a lower level? I know
OOP stuff is out (or is it?), dynamic arrays, GC, lazy functions, etcetera. So
that leaves structs, CTFE, contract programming, mixins, templates, AST macros,
basically any compile time features, correct? I'm sure there are a few others
I'm missing.

 I've been lurking for awhile, and last time I checked there were three
different compilers. LDC looks to be the most promising. What are peoples'
thoughts / experiences with the latest version of LDC?

 How large is D2's runtime? Is it even worth the time and effort to strip down
a custom runtime for kernel use in the first place? In general things need to
be fairly lean, so executable size is a concern.

 Oh, and thanks in advance!

 -Jesse


Looking at was in the runtime (D1):

Associative arrays
opApply for strings
switch
most array related things
cast
exceptions
+ other tings
Nov 12 2009