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
it.
I believe this would also give the user the most convenient
D-compiler (and toolchain).
More information about the Digitalmars-d
mailing list