digitalmars.D - D Kernel Development
- Jesse Robinson <robgunnatkin gmail.com> Nov 11 2009
- Walter Bright <newshound1 digitalmars.com> Nov 11 2009
- Jesse Phillips <jessekphillips gmail.com> Nov 11 2009
- Tim Matthews <tim.matthews7 gmail.com> Nov 11 2009
- Sean Kelly <sean invisibleduck.org> Nov 11 2009
- bearophile <bearophileHUGS lycos.com> Nov 12 2009
- Jesse Robinson <robgunnatkin gmail.com> Nov 12 2009
- Sean Kelly <sean invisibleduck.org> Nov 11 2009
- Bill Baxter <wbaxter gmail.com> Nov 12 2009
- Jacob Carlborg <doob me.com> Nov 12 2009
- Leandro Lucarella <llucax gmail.com> Nov 12 2009
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
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
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
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
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
Walter Bright:You'd need to avoid:
. 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
Jesse Robinson <robgunnatkin gmail.com> bearophile Wrote:Walter Bright:You'd need to avoid:
. 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
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
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=
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
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
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