"Better C" runtime?

[Mike via Digitalmars-d]

On Friday, 25 July 2014 at 12:38:03 UTC, w0rp wrote:
> There were a couple of talks at DConf which made some mention 
> of re-implementing parts of druntime so you can compile D code 
> without druntime. I wonder, do we have any current projects for 
> creating lightweight runtimes? I'm thinking of what it would be 
> like to write library aplications which use @nogc everywhere 
> and expose some extern(C) functions, so you could write C 
> libraries in D instead, such that you could produce lightweight 
> binaries for use in machines which don't have druntime 
> installed on them. I think it would be a fun project.

I'm thinking of actually creating a couple of different runtimes. 
  The one I'm researching right now is intended to be very C-like, 
i.e. no classes, exceptions, garbage collector, runtime type 
info, threads, TLS, etc... Just the most basic parts of D that 
one would need to build a single-threaded kernel. Dynamic memory 
allocation may not even be needed.

Such a runtime would certainly be better than C because there 
would still be CTFE, mixins, templates, etc...  Very cool!  So 
far, my experiments seem to indicate that such a runtime would 
require very little code; potentially less than a few thousand 
lines (famous last words).

If we call that runtime level_0, I then want to build level_1 on 
top of that.  This would include dynamic memory allocation, 
manual memory managment, classes, and anything else that doesn't 
require threads.

Then, on top of that, level_2.  level_2 would add threads, TLS, 
and the garbage collector.  Potentially, level_1 and level_2 
could be merged.  I don't know.  I'm just thinking off the top of 
my head at the moment.

One of the problems I haven't yet solved is what to do when the 
user tries to use one of the missing features.  I'm thinking of 
using the `disable` attribute or static and non-static asserts, 
but I haven't yet experimented with these ideas to determine 
their feasibility.

Another problem I'm currently grappling with is what to do about 
dynamic arrays and other built in types that expect an automatic 
memory manager (GC) to exist.  I'm thinking about just building 
classes to replace these, but I'm not sure just yet.  I would 
love to hear some ideas.

Also, one needs to consider what to do with the stdc stuff.  I, 
personally, want to strip it out.  I don't think D needs to be 
dependent on or ported to the C library.  My goal is to make D 
more autonomous.

I was originally envisioning such a runtime to be used 
specifically for my microcontroller needs, but now that I've 
learned a little more about D and the runtime, I suppose it could 
be made more general purpose.  It may even serve as a nice 
precedent to make the D runtime more modular or tiered, assisting 
with issue 11666 [1].

I'm currently distracted with getting a decent 64-bit GUI 
framework so I can build some utilities and code generators for 
some other parts of my project.  But, If you're really serious 
about pursuing this, let's see if we can reach a consensus on 
design and start building it.  If we keep it minimal, we could 
potentially have it done in a month or two (more famous last 
words).

An execellent prerequisite to this would be to figure out how to 
implement enhancement 12270 [2], so we don't have to do the phony 
object.d TypeInfo nonsense.

[1] https://issues.dlang.org/show_bug.cgi?id=11666
[2] https://issues.dlang.org/show_bug.cgi?id=12270

Mike