"BareBones" VersionCondition identifier for druntime

Kevin Lamonte via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 17 12:04:58 PDT 2014


Hi all,

Following up on the very fun work of Adam Ruppe, Mike (JinShil)'s 
Cortex M howto, XomB, and of course the "D Bare Bones" tutorial 
on wiki.osdev.org, I have started a brand-new kernel in D over 
at: https://github.com/klamonte/cycle

At the moment I am running on i386 (qemu), but aiming for arch 
independence.  I started on GDC but am using DMD now.  The 
current kernel image does little more than allocate/free memory 
and emit strings to VGA memory, BUT it can use D-language 
templates, structs, enums, and (some) classes, all in less than 
50k overhead.

For the runtime, I am using a very minimal 2.065 druntime in the 
"kdruntime" directory (k is for kernel, not my name :) ).  I 
think that kdruntime is (seriously) less than 100 functions away 
from being capable of supporting almost all of the functionality 
described in the D Language Reference, except for: Garbage 
Collection, Vector Extensions, and Interfacing to C++.  I further 
think that the deviations from druntime are in total not that 
large, and that at some future date druntime could be de-coupled 
from libc/posix/windows (if one is willing to re-implement 
threads/synchronized).

*** I am not asking anyone else to do any new work or change 
course on anything right now.  Rather, I would like to ask the 
druntime devs if there is interest in defining a VersionCondition 
identifier, what I am currently calling "BareBones". ***

"BareBones" loosely means "druntime without posix or windows".  
Other words that could be used to capture similar ideas:

   * "Affirmative" definitions: BareMetal, Baseline -- a short 
list of "these features/functions are the absolute minimum 
required to support D2 syntax, after which one could build the 
rest".

   * "Negative" definitions: NoLibC, NoThreads, NoGC -- 
"everything currently in druntime minus these things".

If we had a word like BareBones now, then later on people working 
on kernels (or embedded, or games, or ...) could start offering 
pull requests to druntime to make the job of new mini-runtimes 
much easier.

druntime itself would NOT be expected to compile or link with 
BareBones set.  Most of druntime could be protected from invasive 
changes with just static asserts in modules like core.stdc.*, to 
prevent accidental inclusion in BareBones systems.  Other spots 
that handle platform-specific stuff (like sections.d importing 
sections_linux.d) could import the non-existent 
sections_barebones.d.

New runtimes could be born simply by cloning druntime, setting 
BareBones, removing all the files that static assert fail, and 
then implementing all the functions that aren't found during 
link.  In the near-to-mid term, very little would change for 
druntime.  In the longer term, one or more BareBones-version 
runtimes could emerge to put D in new places.

What do y'all think?  Would you be comfortable with saying to 
people implementing new runtimes, "please version your 
differences from druntime in this particular way" ?


More information about the Digitalmars-d mailing list