www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "Better C" runtime?

reply "w0rp" <devw0rp gmail.com> writes:
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.
Jul 25 2014
parent reply "Mike" <none none.com> writes:
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
Jul 26 2014
next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Saturday, 26 July 2014 at 14:50:43 UTC, Mike wrote:

 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).


The best way to accomplish that is to write it all, then ask for 
pull requests.
Jul 26 2014
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Saturday, 26 July 2014 at 14:50:43 UTC, Mike wrote:

 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.


How do you build an assert message without printf?
Jul 26 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 26 July 2014 at 20:32:15 UTC, Kagamin wrote:

 How do you build an assert message without printf?


Just use the operating system print string function.
Jul 26 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Saturday, 26 July 2014 at 14:50:43 UTC, Mike wrote:

 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).


I find that TypeInfo is just not worth it. You get too much 
without it already and resulting runtime is very small.
Jul 26 2014