[GSoC 2019] Interested in Baremetal D Runtime and project ideas

[Mike Franklin]

On Saturday, 6 April 2019 at 21:31:19 UTC, IGotD- wrote:

> memcpy, memmove and such are heavily architecture dependent and 
> needs an implementation for each architecture (even on sub 
> architecture level) in assembler in order to be optimized. At 
> least this what I've seen for the C/C++ compilers.

This has been my observation as well.  However, DMD only supports 
Intel architectures.  There's still a wide range of feature 
differences in the Intel family, but those can all be managed 
with information like https://dlang.org/phobos/core_cpuid.html

I assume that this GSoC project would focus only on Intel 
architectures that DMD supports, and even then it could always 
fall back to C's `memcpy`, `memcmp`, etc. for those architectures 
that the implementation has not been optimized for.

For LLVM and GDC, they'll probably have to do their own thing for 
all the architectures they support, but I believe DMD could set a 
precedent.

I encourage this project to focus on the fact that this D, not C, 
and there's no reason to follow the C way.  For example, `memcpy` 
in D would probably manifest itself as a template like 
`memcpy(T)(T* dest, const T* src)` or something like that. 
`void*` should go the way of the dodo if at all possible.  
Recognize also that users will likely never need to call `memcpy` 
directly in D.  They would use the wealth of features already in 
the D language, and the compiler should lower those features to 
the `memcpy` implementation on behalf of the user.

> When it comes to malloc and free, I would suggest we have just 
> hooks for these. Baremetal people have very different opinions 
> what allocator suits their needs. Example allocators are of 
> course welcome but being able to change to whatever allocator 
> you want is essential for baremetal.

The implementations in druntime need to be ported to bare-metal 
with facilities like `version(X86_64)` and 
`version(FreeStanding)`, both of which already exist at 
https://dlang.org/spec/version.html  This could be the default 
implementation, and it should be possible to build something in 
that would allow the user to override the default.

Mike