[SAoC] "Druntime for Microcontrollers" project thread

[Denis Feklushkin]

Hi! I am also very interested in this.

This is my unfinished work about porting D to ARM Cortex-M MCU:
https://github.com/denizzzka/d_c_arm_test

Below in the comments I briefly write some thoughts that I came 
by doing this work. Maybe it will be helpful.

On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona wrote:

> A big problem I encountered while porting the userland was the 
> fact that the Druntime was not built for the target 
> architecture and even if it would have been, it would not have 
> fit the memory on the device.

Link Time Optimization (LTO) is available in LLVM-based ldc2 and 
can dramatically (2-3 times!) decrease .text size.

> Starting from this point, I have decided to participate this 
> year at Symmetry Autumn of Code and create a micro-runtime for 
> the D language, to be used with microcontrollers and memory 
> constrained devices.

Thought about this while working on my project and came to 
conclusion that it makes no sense to write a new druntime. There 
is nothing superfluous in the existing "regular" druntime, any 
part of it is needed for key concepts of D.

> During SAoC, I have planned the next steps:
>
> Milestone 1: Build a runtime (doesn’t matter the size yet) for 
> the specified architecture:
> - Try to build the runtime for the Cortex-M CPU architecture:
>  * either by using the ‘ldc-build-runtime’ toolchain (which 
> currently fails because of a ‘CMake’ error)
>  * or by building and compiling manually the source code
> - If the build succeeds, I won’t be able to test it because the 
> size of the druntime doesn’t fit in the microcontroller’s 
> constrained resources.

QEMU have -m option to add slightly more memory into emulated 
Cortex M3 devices - can be useful to fit all druntime tests.

> - Begin removing unnecessary functionalities (that a code 
> running on a microcontroller does not need) from the ‘object.d’ 
> file (most probably by stubbing the code)
>
> Milestone 2:  Try to have a small object.d implementation
> - Continue removing any functionality a small class doesn’t 
> need.
> - Try to test the new ‘object.d’ on the microcontroller after a 
> successful build of the file.
>
> Milestone 3: Attempt a port of the current Garbage Collector
> - Try to port the current GC for the target architecture
> - If that fails in the first 2 weeks, try to implement a 
> small-sized GC from scratch (this could exceed the deadline of 
> this milestone)

As I remember, current default Garbage Collector just works - it 
is not need any porting.