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

[Mike Franklin]

On Thursday, 4 April 2019 at 13:56:08 UTC, Stefanos Baziotis 
wrote:

> I'm mainly interested on the Baremetal D runtime project, as I 
> am mostly comfortable
> with low-level C programming. I have developed some allocators 
> [1]
> and have some SIMD experience as I have written a small image 
> convolution MPI
> program that uses AVX extensions [2].

I'm sorry for responding late; I didn't see this thread until 
just a short while ago.

I think there are probably a few different ways to define a "bare 
metal runtime in D".  The way I define it is "port the existing D 
runtime to a processor that is not running an operating system".  
The problem with that is D's runtime expects an underlying 
operating system.  So, one is left with a bit of a paradox:  
which comes first the operating system or the runtime.

I would argue that if one is porting the existing D runtime to a 
processor without an operating system, the runtime becomes the 
operating system.  Therefore, one needs to implement dynamic 
memory allocation, threads, exceptions, thread-local storage, the 
garbage collector, etc. all in the runtime, and all unique to a 
specific processor or processor family.  Basically, one needs to 
build an operating system into the D runtime.
In a way, that's pretty cool, as D itself would then come with an 
operating system included, but is that really practical?

Perhaps what users are actually looking for is a minimal subset 
of D that doesn't require a runtime. That would likely mean no 
dynamic memory allocation, no threads, no thread-local storage, 
no GC, no classes, no exceptions, or some variant of that. That's 
more or less what -betterC provides.  Perhaps one could use 
-betterC to build the OS on which the full D runtime would be 
ported to.

What I would like to see is neither of those, but what Andrei 
recently proposed with this comment:

> Oh, and druntime must go.
>
> The whole distinction between the runtime library and the 
> standard library is clowny and has more to do with poorly 
> ported tradition from other languages, than with anything else.
>
> We need one standard library that is entirely pay-as-you-go 
> (e.g. empty main() means no library file is ever needed for 
> linking) and that offers an opt-in continuum.

In my opinion, that is smack dab right on and said better and 
more succinctly than I ever could.  But, how do we get there?

As I see it, we actually have the vast majority of it already 
implemented, but with all the dependencies on C, C++, operating 
system APIs, and a design philosophy the operating system and 
C/C++ toolchain would always be there from the beginning, we have 
a tangled mess.

So, we need to untangle everything and reduce the implementations 
down to individual, modular components with minimal dependencies 
that can be imported without bringing in everything else.  Here's 
Andrei delegating a few tasks to me:  
https://www.youtube.com/watch?v=uUQeQ7E8hOU

A great help will be if Dan Printzell succeeds in eliminating the 
dependency of many runtime hooks on TypeInfo.  Since TypeInfo is 
a class, his project will help eliminate the dependency on 
classes, and since classes more-or-less require the GC, it 
removes the dependency of those runtime hooks on the GC as well. 
It will also decouple the compiler from the runtime allowing it 
to generate code with fewer dependencies.

However, those runtime hooks still require implementations in 
terms of memcpy, memcmp, malloc, free, etc.  Having those written 
in D as strongly-typed templates would further reduce 
dependencies on a C/C++ toolchain and standard library.  With 
Dan's work completed, the benefits of having memcpy, malloc and 
friends implemented in D would become much more apparent, as the 
new runtime template lowerings could then be implemented in D all 
the way down the stack utilizing CTFE, design by introspection, 
and all of D's compiler guarantees such a safety and purity.

Finally, I think it would help greatly if we could detangle and 
pull out those features of Phobos that don't require any runtime 
support (e.g. std.traits, std.meta) that would provide a base, 
lightweight, no-dependency utility library for all D platforms 
including bare metal.

Mike