[GSoC] Trying to find a good topic

Johannes Pfau nospam at example.com
Thu Mar 21 21:54:12 UTC 2019


Am Thu, 21 Mar 2019 19:50:49 +0000 schrieb Dan Printzell:

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

I think what we should do for betterC is to first replace the extern(C) 
hooks with a defined API. Right now, the compiler does not know if a 
runtime has feature X, it simply calls an extern(C) function _featureX(). 
If this functions is not in the runtime, this fails at link time only. A 
better approach would be to use a D function featureX in object.d. The 
compiler can then import object.d and see if there is a function 
featureX. If not, the runtime does not support the used feature and the 
compiler should emit an error.

This way, we can implement a truly modular runtime. Just implement some 
feature and the compiler will allow using it, do not implement it and the 
compiler will error if you try to use it. In the extreme case, this means 
we can use a D compiler without any runtime and it will gracefully 
degrade to a reduced subset.

Ideally, we can then implement different parts of the runtime in dub sub-
packages. We could then ship a gdc for embedded targets without any 
default runtime and it would just work for some basic runtime. If you 
need classes, constructors, ... include microdrt:core. If you need 
unittests include microdrt:unittest (:exceptions, :gc, ...). For the C 
library, we should have some extra package stdc. We might also want a 
package for device-independent, portable code (volatile wrapper, 
traits, ...). We could then also use different configurations for 
microdrt:core, where the default 'ansic' would just use ansic features 
and be portable everywhere where a C lib is available, 'native' would 
work without a C lib, etc.

https://wiki.dlang.org/GSOC_2019_Ideas#GDC_.28GCC-based_D_compiler.29

Whether this should replace druntime in the long term is probably a very 
difficult question. I'd say start small, with a minimal core runtime 
which is suitable even for the smallest 8bit microcontrollers. Getting 
the full featureset of druntime in there in a modular runtime is probably 
too much work for GSoC, but as a long-term goal it would be prefereable 
to only have one runtime. However, druntime is not the place for such 
radical restructurings.

-- 
Johannes


More information about the Digitalmars-d mailing list