[GSoC] Trying to find a good topic

kinke noone at nowhere.com
Thu Mar 21 21:01:51 UTC 2019


I'm sure you'd be of great help. :)

On Thursday, 21 March 2019 at 19:50:49 UTC, Dan Printzell wrote:
> 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

Wrt. DIP1014, I tried to point out in the discussion that it 
probably needs a D ABI change (I know that it definitely will for 
LDC). We're not talking about a trivial minor adaptation, but a 
change affecting all non-POD arguments passed by value - don't 
copy in registers or on the stack anymore and let callEE destruct 
it, but have callER create a temporary, pass it by ref and then 
destruct it by callER (also when callEE throws), just like C++. 
As a nice side-effect, this will also fix C++ interop in this 
regard.

At least for LDC, there are some implicit moves emitted by the 
compiler in the glue-layer between front- and backend; I assume 
that's also the case for DMD.

I don't think a full 3 months of GSoC would be needed for a 
working implementation, but the effort is easily underestimated 
IMO. And sadly, it's not a pure front-end thing, so other 
compilers will have to reimplement some/most? parts.

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

IMO, it should indeed be something like a druntime-lite without 
any external dependencies, and druntime build on top of it. 
Containing the 'absolutely essential runtime bits for the core 
features' (to be defined ;) - e.g., (most?) runtime functions 
implicitly invoked by the compiler, e.g., for array 
copying/initializing). As a goal, it should be fairly simple to 
add support for any new target, e.g., WebAssembly and a new OS 
like your PowerNex.


More information about the Digitalmars-d mailing list