RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)

Jens Bauer via Digitalmars-d digitalmars-d at puremagic.com
Sat May 9 23:55:05 PDT 2015

On Sunday, 10 May 2015 at 01:55:53 UTC, Mike wrote:
> On Thursday, 7 May 2015 at 14:48:08 UTC, Jens Bauer wrote:
>> I already have supplied those options in my toolchain.
>> But does anyone know if this is advisable when using FreeRTOS 
>> (or any other RTOS for that matter) ?
>> -I'm asking, because I'm not using any RTOS myself, but there 
>> are loads of people who do.
> In order to make the full stack in D, I think we eventually 
> will need to make 2 toolchains: a bare-metal kernel toolchain, 
> and an application programming toolchain.

That does not sound too appealing, because as far as I know, you 
have your bare-metal arm-none-eabi toolchain with C and C++, 
which can build RTOS. Then you'll need another arm-rtos-eabi, 
which can build RTOS, but cannot build bare-metal. I think people 
will not like this, because they don't want to switch toolchains 
when they work on different projects.
The arm-linux-eabi toolchain will be a third toolchain, because 
RTOS is not Linux, though Linux may be some kind of RTOS. ;)

> The bare-metal kernel toolchain would not have some of the 
> high-level features of D, like threading and synchronization, 
> as that has yet to be built.  However, once a D RTOS is created 
> with all necessary features for theading and synchronization, 
> then the application programming toolchain can be made with a 
> druntime ported the D RTOS's API.

Another (annoying) input: If I decide to write a context-switcher 
in assembly language, I suddenly have threads, which I'd of 
course like to be able to use with my bare-metal toolchain.

> I've also considered another interesting approach.  It seems 
> possible to port all features of D right to the metal, 
> essentially embedding the RTOS directly into the runtime.  Then 
> D is your RTOS :-)

I do like this approach better, and that resembles the way I've 
been thinking until now.
Yes, it might require more work, but strongly I think it's worth 
I believe this would also give the user the most convenient 
D-compiler (and toolchain).

More information about the Digitalmars-d mailing list