What is the state of Microcontroller support in d?

Mike via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 20 00:51:47 PDT 2017


On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote:

> Hi you still around, I'm starting to investigate these issues 
> and see if I can start using D in some of my embedded projects 
> at my company. I've got stuck at the hurdle of trying to use 
> minilibd with Ldc compiler, did you make progress since this 
> post?,

IMO microcontroller support in D is only slightly better than 
non-existent.  I tried about 2 or 3 years ago to move the ball 
forward on it, but just ran into way too many obstacles.  The 
nail in the coffin for me was 
https://issues.dlang.org/show_bug.cgi?id=14758.

To enumerate some of the problems (I don't have the energy for an 
exhaustive list, so these are just off the top of my head at the 
moment)

1.  Compiler-runtime coupling.  The compiler expects too much of 
the runtime to exist even when what it requires has no hope of 
ever being executed in the resulting binary.  So, it forces us to 
implement silly hacks and stubs just to get a build.

2.  The compiler adds things that aren't even needed in the 
resulting binary, and does so in a way that prevents 
--gc-sections and LTO from removing them.  For some of my code, 
the binary was so large it wouldn't even fit on the 
microcontroller's flash memory.

3.  Many of the veterans in the D community support the current 
dependency the runtime has on C standard library bindings, 
stating that they are required (which is not true).  Furthermore, 
they want to make the problem worse by adding C++ standard 
library bindings as well.  I submitted  pull request to begin 
moving these bindings to Deimos, and make the dependencies 
private for individual platforms' ports, but only encountered 
resistance and misunderstanding.

4.  The D gatekeepers have become very averse to anything that 
would cause too much disruption, making me believe that the 
fundamental changes that are needed to make microcontroller 
programming in D a reality will never be accepted.

5.  Too many pull requests sit in "purgatory" for way too long 
without any progress.  I believe that trying to move my changes 
forward would be an uphill battle, and ultimately not worth the 
frustration.

6.  Rust has "minimal runtime" as one of the pillars of its 
language design philosophy.  You can truly pay-as-you go while 
you build your system.  This is how it should be, and unless 
you're looking for a fight, you'll probably be better off there:  
http://blog.japaric.io/quickstart/.  That's where I'm allocating 
my resources these days.

Mike








More information about the Digitalmars-d mailing list