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

Stefanos Baziotis sdi1600105 at di.uoa.gr
Sat Apr 6 22:23:39 UTC 2019


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. We can have 
> a fallback in D though. Correct me if I'm wrong, doesn't LLVM 
> provide with such primitives, at least partly?

I believe that you are correct about LLVM [1]. It seems though
that it calls the C standard library.

I would be glad to listen to the creators of the project idea
about the clear goals of this project, but this is my take:

1) Independency in the C standard library. Being dependent on the
C standard library means that users have to have a C toolchain.

2) It tries to target limited resources systems and as such
the focus will be in those archictures.

3) C versions are nowadays quite complex, so they might want
simpler versions.

4) As Mike states in github, take advantage of the templates and
compile-time execution for potentialy more efficient code and also
the strong type system to leverage features such as @safe.

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

I think that the reasons to implement malloc() and free() are
the same with those of memcpy etc.

Any enhancement on the reasons is welcome.

[1] 
https://llvm.org/docs/LangRef.html#standard-c-library-intrinsics

- Stefanos


More information about the Digitalmars-d mailing list