"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