What is the state of Microcontroller support in d?

Dan Walmsley via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 20 07:12:36 PDT 2017


On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:
>
>> If we push to have this fixed after that we are pretty close 
>> to having something usable are we not?
>
> Depends on your definition of "usable".  Fixing the bloat issue 
> would remove a current road block, and at least allow progress 
> to continue.
>
> IMO, to make D a pleasant experience on the ARM Cortex-M 
> platform, we'll need to implement the entire druntime including 
> threading, GC, exceptions, dynamic arrays, etc... even if those 
> features are not used.  This is because D just hasn't been 
> designed and implemented in a modular fashion to allow one to 
> pay-as-they-go, and as you experienced in one of your other 
> posts today, you just get too many undefined references and 
> other odd errors that have nothing to do with your code.  The 
> only way to make those errors go away is to ensure everything 
> in druntime is there.
>
> If the bloat problem were solved, we could at least continue 
> working towards that end.  But it's not immediately apparent to 
> me how much overhead a complete runtime implementation will add 
> to as simple microcontroller application, and how well the 
> compiler and linker can optimize and remove that overhead.  We 
> may encounter other roadblocks like I did with the TypeInfo 
> bloat, and have to fight a major battle to get something done 
> about it.
>
> But I don't want to have to implement the entire druntime in 
> order to start making progress.  It shouldn't have to be that 
> way.
>
> Mike

I completely agree with you here, its a real shame! Id be happy 
to put some effort into this, I don't know if you can help me put 
pressure on the right people to get the bloat thing fixed. It 
seems like its probably fixed in dmd compiler, but none of the 
others. I think ldc2 is the compiler that has the most potential 
because it can easily be compiled unlike the gdc one and then dmd 
one doesn't seem to support arm out the box unless things changed 
recently.

I'm happy to have a GC on a system like stm32, as I read it only 
collects on calls to new, and most sensible embedded designs 
would just allocate at initialization and not during runtime.

Threading I think we could easily use freertos or something 
underneath.

Which just leaves dynamic arrays and exceptions which I know next 
to nothing about right now :)

Firstly who do we need to talk to about the bloat in LDC?



More information about the Digitalmars-d mailing list