Hi all,

I am Teona Severin and I am a first year Masters’ Degree student at University Politehnica of Bucharest. During my bachelor’ years, I was most interested in fields such as Operating Systems, Programming Languages and Paradigms and Embedded Systems, with a focus on the Internet of Things.
Learning new programming languages and understanding the way a compiler interacts with the operating system were the most fascinating things I have learned in my last 4 years of study. After studying different programming languages like Prolog, Haskell or Java, in the summer of 2019 I was introduced to the D-Language by Eduard Stăniloiu and Răzvan Nițu during a workshop at the summer-school I was volunteering for, “Ideas and Projects Workshop”.
Being an Internet of Things enthusiast, I began wondering whether it was possible or not to use D with different types of embedded and resource constrained devices. This is why I chose as my bachelor project “D-Language for IoT systems”. This project consisted in writing a few libraries for high-performance embedded systems (such as Raspberry Pi or BeagleBone Black), through which one can access different pins exported by the device (I2C[1], GPIO[2] or ADC[3] pins). Also, I have ported TockOS’ [4] C userland to D[5], in order to run D code on microcontrollers based on ARM Cortex-M CPUs (TockOS’ target systems).
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. As a conclusion, I had to use ‘betterC’, a very useful concept for devices with little memory, but lots of functionalities such as classes, GC or exceptions could not be used.

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. Up until now, I have managed to compile and run D code on microcontrollers with “betterC” but only without the standard D library and runtime and of course, without key concepts of D Languages.
This project combines perfectly all the fields I have an interest in: programming languages, understanding the way the compiler works (with or without an operating system) and embedded systems.

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

Milestone 4: Stress test and further implementations
- If the GC is ported, begin to stress-test the runtime
- Write a few drivers that actively use classes and communicate with different devices (an LCD screen, a temperature sensor, etc).
- If everything goes well, begin research for porting other concepts like Exceptions or Errors.
- If the GC is not ported at the beginning of this milestone, finish the GC and stress-test in the remaining time.

I will keep you posted weekly with everything I manage to do (or I don’t manage to do).

Thank a lot,
Teona.

[1]: https://github.com/DLang-IoT/i2c
[2]: https://github.com/DLang-IoT/gpio
[3]: https://github.com/DLang-IoT/adc
[4]: https://www.tockos.org
[5]: https://github.com/DLang-IoT/libtock-d

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.

On 14/09/2020 9:11 PM, Denis Feklushkin wrote:
> As I remember, current default Garbage Collector just works - it is not need any porting.

Not true, there are some OS bits that need dealing with[0].

[0] https://github.com/dlang/druntime/blob/master/src/gc/os.d

On 14/09/2020 7:59 PM, Severin Teona wrote:
> 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)

If you fail the first 2 milestones, you won't have access to classes and hence won't have access to anything GC related.

Classes and TLS are the two biggies that make porting to micro controllers hard. Good luck!

Hi Denis, thank you for your answer.

On Monday, 14 September 2020 at 09:11:07 UTC, Denis Feklushkin wrote:
>
> This is my unfinished work about porting D to ARM Cortex-M MCU:
> https://github.com/denizzzka/d_c_arm_test
>

Thank you for sharing this with me, I will take a look at what you have done there.

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

Hmm, I will try this as soon as I manage to compile the runtime for the Cortex-M, because right now that the big issue for me. The 'ldc-build-runtime' tool fails for Cortex-M and I cannot find another way to build it. I have also tried to manually compile everything, but I could not get anywhere.

I have posted a question regarding the error I get when I try to compile the runtime on the Learn thread: https://forum.dlang.org/thread/btiahosjluxddsjjnleq@forum.dlang.org.

I would appreciate if you could help me find a way to solve this.

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

Thank you, I will try to do that too.

On Monday, 14 September 2020 at 13:00:23 UTC, rikki cattermole wrote:
> On 14/09/2020 9:11 PM, Denis Feklushkin wrote:
>> As I remember, current default Garbage Collector just works - it is not need any porting.
>
> Not true, there are some OS bits that need dealing with[0].
>
> [0] https://github.com/dlang/druntime/blob/master/src/gc/os.d

This is only sort of "tuning"

On Monday, 14 September 2020 at 15:00:31 UTC, Severin Teona wrote:

> Hmm, I will try this as soon as I manage to compile the runtime for the Cortex-M, because right now that the big issue for me. The 'ldc-build-runtime' tool fails for Cortex-M and I cannot find another way to build it. I have also tried to manually compile everything, but I could not get anywhere.

Faced with this too. At this stage I choosed Meson build system and moved druntime build to it:

https://github.com/denizzzka/druntime/blob/non_posix/meson.build

Meson supports fine-tuning of build process with all these tons cross-compiling options.

I remembered one more "hint" to avoid confusion of options, etc: don't use "bare metal" term. Just assume that you are implement druntime support for a new unusual operating system.

Hi Denis!

On Monday, 14 September 2020 at 17:34:22 UTC, Denis Feklushkin wrote:
> On Monday, 14 September 2020 at 15:00:31 UTC, Severin Teona wrote:
>
> Faced with this too. At this stage I choosed Meson build system and moved druntime build to it:
>
> https://github.com/denizzzka/druntime/blob/non_posix/meson.build

I followed your advice and started to take a look at Meson build system. But I can't seem to succeed in building the druntime. Is there something not so straightforward that I'm missing in order to make it work?

> Meson supports fine-tuning of build process with all these tons cross-compiling options.
>
> I remembered one more "hint" to avoid confusion of options, etc: don't use "bare metal" term. Just assume that you are implement druntime support for a new unusual operating system.

On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona wrote:
> [...]

How does your work relate to:

https://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler

https://github.com/denizzzka/D_minimal_Cortex-M3

https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona wrote:
> [...]

cool thanks for this project! I have before also used D on AVR devices (8 bit microcontrollers) where I ported libc-avr to D here: https://github.com/WebFreak001/avrd

Maybe that will help you get the idea of how to get D running on a completely different hardware with betterC first. For porting object.d and the druntime check out Adam D. Ruppe's WebAssembly object.d, which is a very minimal good starting point where you just add features incrementally as you need them.

Don't forget to make a post when you get a basic D application with the most minimal runtime (just object.d without phobos and a lot of druntime) running with TockOS, I would love to try it out running it on my PineTime which I wanted to program for a while now!