[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