[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