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.

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

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.

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?

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.

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.