[GSoC 2019] Interested in Baremetal D Runtime and project ideas

[Mike Franklin]

On Sunday, 7 April 2019 at 10:56:51 UTC, Stefanos Baziotis wrote:

> Mike, you give informative answers. To be honest, the more
> I discuss this project idea, the more unclear what the goals
> are becomes.

These are the goals as I see them:
1. Allow for the opt-in continuum described here:  
https://forum.dlang.org/post/q7j4sl$17pe$1@digitalmars.com

2. Remove artificial dependencies.  IMO the current dependency D 
has on C is completely artificial.  D does not need C 
(https://forum.dlang.org/post/kemnbymcuwycglevtbox@forum.dlang.org).  It's simply utilizing C as a matter of convenience and expediency.  Many of C's implementations are not type and memory safe, and that is a disadvantage for D.  C's implementations can't be evaluated at compile-time, that is a disadvantage for D.

3. Detangle dependencies.  e.g. many of the runtime hooks don't 
need runtime TypeInfo; that information is available at 
compile-time.  This also applies to modules in Phobos.  e.g. 
std.traits, std.meta, std.conv, shouldn't require runtime support.

4. Embrace design by introspection 
(https://www.youtube.com/watch?v=tcyb1lpEHm0) all the way down 
the call stack.

5. Embrace D's compiler guarantees (type safety, memory safety, 
purity, etc.) all the way down the call stack

It is the opt-in continuum that enables bare-metal programming in 
D. (2)~(5) are just things that need to be done to get there.  We 
don't need -betterC; users can simply opt-in to the features they 
want by importing the modules they need, and no more.

Currently, the compiler assumes an OS is present.  It assumes the 
*entire* druntime library is complete and available at both 
compile-time and link time.  Well, at least it used to; v2.079 
introduced some improvements 
(https://dlang.org/changelog/2.079.0.html#minimal_runtime).  We 
need to continue that work until (1) becomes a reality.

Converting C's software building-blocks to D is not absolutely 
necessary for bare-metal programming, but it will make for a more 
polished experience and will truly embrace the zen of D if the 
conversion were done.  I'm under the impression, also, that once 
converted to D, some D programs will out-perform their C 
counterparts.

I think the GSoC idea was ported from a number of different ideas 
proposed at the Symmetry Autumn of Code here:  
https://wiki.dlang.org/SAOC_2018_ideas#Re-implement_Software_Building_Blocks_.28e.g._memcpy.2C_memset.2C_memcmp.2C_malloc.2C_free.2C_etc..29_in_D

Don't worry about what's posted at GSoC ideas page.  Understand 
why converting these software building blocks to D would be 
advantageous and make the case for it in your proposal, and why 
you should be the one to do it.

If it's difficult to see why converting them to D would be 
advantageous, well, that's probably my fault.  I don't know how 
else to say it.  As I mentioned previously, once the runtime 
hooks are converted to templates, it should become much more 
apparent to all without me having to advocate for it.

Mike