Druntime for Microcontrollers

teonaseverin commented 3 years ago

Description

I have been working with D programming language for the past year and have been trying to integrate it in embedded systems applications. For the high-performance devices, like Raspberry Pi and BeagleBone Black, I have written a few libraries to ease the interaction to the boards’ exported pins. I have written libraries for the GPIO (1), ADC (2) and I2C (3) pins using different mechanisms to communicate with the operating system (sysfs for GPIO or device drivers for I2C). The next step was porting the TockOS’(4) userspace to D(5), in order to write D code to be run on microcontrollers (the target devices for TockOS). I have started from the current C userspace, the most used userspace for TockOS. Unfortunately, there were some problems I encountered while working on this project: there is no official version of the druntime for such devices and so, a number of functionalities are lost: classes, Garbage Collector, or errors and exceptions. Also, I had to use and import the C standard library ported for the target architecture. Practically, the code was written in D, but lots of functionalities were borrowed from C.

The aim of this project is to create a small sized runtime for D-Language for microcontrollers based on ARM Cortex-M CPUs (for other architectures like RISC-V there seems to be no compiler that can cross-compile D code yet). These microcontrollers usually have little RAM and flash memory and the size of the standard druntime is incompatible with these devices. At the time being, D code can be run on microcontrollers without druntime by using betterC (using the LDC compiler) or by including an empty “object” module (using GDC (6)) . BetterC uses the C standard library cross-compiled for the target architecture. This way lots of functionalities that differentiate D from C, such as classes or string concatenation, are lost.

The final purpose of the project is to run on a microcontroller a simple application that actively uses a class: maybe a driver for a peripheral device, like an LCD display. Of course, a minimal Garbage Collector that ensures no memory leaks are present is essential for efficient behaviour.

Lately, I have been trying to cross compile the current runtime for the ARM Cortex-M CPUs, but the way it is written and the interdependence between modules makes it impossible to extract only one functionality. Also, the size of the compiled druntime would have exceeded the microcontroller’s resources.

What are the rough milestones of this project?

Decide whether to (1) rewrite the runtime from scratch by extracting the essentials from the current druntime, or (2) add support for ARM Cortex-M into the master repository, by means of versioning. Going with option (1) would probably be easier to start with, but option (2) would have the benefit of always being in sync with the master repository. An important issue of option (2) will be represented by the total size of druntime, that might not fit in the small resources of a microcontroller.
Write the object.d source file only with the necessary functionalities for using a simple class and the new keyword. Probably, this will be done by stubbing most of the object.d module
Attempt a port of the current Garbage Collector implementation. If this fails, develop a simple and small sized Garbage Collector
If everything works, we will go further with the research to see if concepts like exceptions or errors can be integrated in the druntime

How does this project help the D community?

D is not a first choice when it comes to IoT and embedded systems applications. With this project, I hope that D-Language will be more popular among these fields. Also, I believe that complex concepts like classes or GC, ported for an embedded device with maximum 10MB of flash memory, are a step forward in the growth process of the D programming language.

Recommended skills

D programming - what is a class, how you use it, understanding all of D’s functionalities
understanding of the “runtime” concept - what it is, how it works, how the compiler interacts with it
operating systems knowledge - what the compiler includes, how dynamic libraries work
patience - this is also a research project

(If applicable, e.g. GSoC/SAoC)

What can students expect to get out of doing this project?

In the first place, I believe this project will help me understand D even better, because understanding “the backend” of any programming language (compiler, runtime and standard libraries) is way better than using the “API” that programming language is exporting to the user. Also, this would be an important contribution both to the D language and to the embedded systems field.

Point of Contact

@edi33416 @RazvanN7

References

1: https://github.com/DLang-IoT/gpio 2: https://github.com/DLang-IoT/adc 3: https://github.com/DLang-IoT/i2c 4: https://github.com/tock/tock 5: https://github.com/DLang-IoT/libtock-d 6: https://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22

wilzbach commented 3 years ago

Write the object.d source file only with the necessary functionalities for using a simple class and the new keyword ... Attempt a port of the current Garbage Collector implementation. If this fails, develop a simple and small sized Garbage Collector

Why not continue on the prior work to make the Garbage Collector more optional and allow to use reference-counting for classes, arrays etc.? There's a lot of interest in this (and a bit of prior work).

Other languages are going this way too, see e.g. Nim's GC CLI flag.

RazvanN7 commented 3 years ago

@wilzbach Using reference counting for classes instead of the gc is, most likely, not going to fix the size issue (the current size of the compiled druntime is too big for the resources of microcontrollers) so part of the project is understanding what is the minimal subset of features that are required be able to use druntime on microcontrollers.

wilzbach commented 3 years ago

Well, if you don't have a GC you have a better shot at getting rid of TypeInfo etc. So we're at least continuing the work in converting more hooks into templates to be able to cut down on the default size and make the runtime more pay as you go?

RazvanN7 commented 12 months ago

Closing this issue as it morphed into replacing the druntime hooks with templates which already exists and is being worked on: https://github.com/dlang/project-ideas/issues/25.

dlang / project-ideas