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