[GSoC] Trying to find a good topic

[Mike Franklin]

On Thursday, 21 March 2019 at 19:50:49 UTC, Dan Printzell wrote:

I'll attempt to answer your specific questions below.

> For dmd I am primarily interested in implementing DIP1014[3], 
> as this will help
> me with the development of PowerNex. In the past I had to 
> workaround that this
> feature was missing. From the outside is seems like this would 
> not take too long
> to implement, at least not a whole GSoC. But as I'm not too 
> familiar with dmd's
> source code, I only did a few small patches to allow dmd to 
> support PowerNex as
> a target[4].
> So my question for this topic would be: How long time do you 
> guys think that
> this will take to implement, test and get it merged? Is a month 
> about correct?

I'm afraid I haven't looked into this and I don't have anything 
to share. Sorry.

> For the betterC topic I would be interested in implementing a 
> bare metal D
> runtime[5]. This is something I already have some experience as 
> I have written a
> betterC runtime for PowerNex, and I also used to 
> update/maintain Adam D. Ruppe's
> minimal.zip[6] when I used that as the runtime for PowerNex.
> My question would be: What features should this runtime contain?

As I see it there are 3 different levels:

Level-0:  No dependencies whatsoever. Level-0 would likely only 
include utilities, but more features could be added if you chose 
to import `memcpy`, `memset`, and `memcmp` from libc.  However, I 
would prefer if those software building blocks were implemented 
in D.  See https://github.com/JinShil/memcpyD for an unfinished 
exploration.  Level-0 would not include dynamic heap memory 
allocation, but could utilize dynamic stack memory allocation.  
LDC and GDC have alloc out of the box, but DMD doesn't 
unfortunately, so you might have to hack something together with 
static arrays and runtime error-checking. See more about this at 
https://forum.dlang.org/post/yyylugjalnlawjvxaqfp@forum.dlang.org

Level-1:  Imports Level-0, but also adds dynamic heap memory 
allocation and any D language feature implementations that depend 
on it.  You could import libc for `malloc`, `free`, and friends, 
or they too could be implemented in D super extra credit.

Level-2:  Imports Level-1, but also adds threads.  Once threads 
are implemented D features such as thread local storage and the 
GC become possible.  Subsequently, with the GC, you can now 
implement classes and the rest of druntime.  I think you could 
implement the GC in Level-1, but I haven't thought it through yet.

If those three levels were distributed separately, a user could 
potentially opt into whatever level they desire for their 
application.

> From the wiki I
> see that basic libc functionality is requested, like the str* 
> functions and
> memory management. From what I can understand, the goals it to 
> have a runtime
> that can be used on multiple targeted environments, without any 
> external
> dependencies.

Yes, no dependencies on anything non-D is my preference.  It is 
possible to replace the facilities currently being leveraged from 
libc, but will take a lot of work, and a significant project 
itself.  For the short-term, however, we can tolerate a libc 
dependency, or you could make replacing these facilities your 
project.

> Other questions regarding this topic: how separate should it be 
> from druntime?
> Should this be a separate library, like a druntime-lite? or is 
> the goal to allow
> druntime to be used for a bare metal target? Also, should this 
> only be betterC
> or should it support regular D as well?

I don't really think about it as being separate from druntime.  I 
see it as just an alternate implementation of druntime; one that 
is more scalable and pay-as-you-go than what we currently have.

> Depending on the implementation size of DIP1014 and the bare 
> metal D runtime,
> it seems like both could be implemented during a GSoC. But I am 
> probably just
> being time optimistic here.

Sound WAY too optimistic for me, but who am I to judge?

I'll restate, briefly, what I said in my other post, that I think 
there are some fundamental changes to DMD and druntime (e.g. 
replacing runtime hooks with templates) that should probably be 
implemented first as prerequisites to all of this, and I can help 
with that.

Mike