D in MPLAB FOR PIC32

Fri Jan 6 16:39:47 PST 2017

On Friday, 6 January 2017 at 15:47:21 UTC, Igor Myronov wrote:
> Is possible to program in D micro*-controllers like the PIC32 ?
> Thanks to all.

D has 3 compilers DMD, LDC, and GCC,

DMD only has a backend for Intel CPUs.  LDC uses the LLVM 
backend, but I don't see an LLVM backend for PIC.  GDC uses GCC's 
backends, but again, I don't see a backend there for PIC either.

LLVM and GDC both, however, have backends for other 
microcontrollers, specifically ARM Cortex-M (search for ST 
Discovery[1], Teensy, Adafruit Feather, Arduino Zero).  There was 
even some success a few years back testing D on an Atmel AVR [2].

The Arduino 101 [3] uses an Intel Quark MCU, so it may be 
possible to program that using DMD, but to my knowledge, noone 
has tried.

[1] - D on ST Discovery - 
https://github.com/JinShil/stm32f42_discovery_demo
[2] - D on Atmel AVR - 
https://github.com/D-Programming-microD/avr-playground
[3] - Arduino 101 - Intel Quark MCU - 
https://www.arduino.cc/en/Main/ArduinoBoard101

That all being said, as being one spent some time exploring D on 
microcontrollers, I can't recommend it.  The problem is that the 
D compiler is tightly coupled to the D runtime, and expects a 
full-featured runtime in order to get build [4] [5] (even if your 
code doesn't make use of the features).

I'm the one who wrote the previously mentioned ST Discovery proof 
of concept [1], and in order to reduce code bloat from the D 
runtime, I had to compile to assembly, use a sed script [6] to 
modify the assembly, and then recompile the assembly to the 
binary.  Sometimes it didn't even work. The binary was 600K 
without the sed script, and 6K after the sed script.  There is no 
way such huge binary sizes can be used for microcontrollers, and 
the hacks to get around it are just too ridiculous for me 
recommend D for this kind of work.

An issue [7] for this problem was created, but the solution 
wasn't implemented properly to allow the LDC and GDC backends to 
benefit.  And since DMD doesn't support ARM Cortex-M, it was 
essentially useless.

[4] - Demonstration of D compiler-runtime coupling - 
http://forum.dlang.org/post/kfspvnrbykweyowjtkkl@forum.dlang.org
[5] - D compiler-typeInfo coupling - 
http://forum.dlang.org/post/nevipjrkdqxivoerftlw@forum.dlang.org
[6] - Sed command to reduce code bloat - 
https://github.com/JinShil/stm32f42_discovery_demo/blob/master/build.d#L69
[7] - TypeInfo code-bloat issue - 
https://issues.dlang.org/show_bug.cgi?id=14758

DMD has a switch called -betterC [8] which was intended to use a 
C-like dialect of D, but it was never fully implemented. One 
problem with the whole idea of the -betterC switch is it's not 
granular enough to disable only some features, but not others, so 
its not a good solution anyway.  I believe there are better 
solutions [9].

[8] - An interesting read on the -betterC switch - 
http://arsdnet.net/this-week-in-d/2016-oct-09.html
[9] - Proposal to decouple D compiler from D runtime - 
http://forum.dlang.org/post/psssnzurlzeqeneagora@forum.dlang.org

The 2017H1 vision document [10] mentions two items ('Templatize 
dmd <-> druntime API' & 'Better support for C-style libraries 
with light or no runtime') that will help this situation, but 
they are not high priority.  The latter is not well-defined 
enough for anyone to do any real work without facing an uphill 
battle justifying their changes to others.  D places a 
disproportionate high priority on stabilization, so any changes 
that may improve matters, but will cause too much disruption, 
will likely not be accepted.

[10] - 2017H1 D Vision - https://wiki.dlang.org/Vision/2017H1

Due to D's shortcomings in this domain, so I have been exploring 
Rust.  Rust has placed a high priority on ensuring it has a 
minimal runtime [11], so microcontroller programming in Rust is 
really taking off [12] [13] [14].

[11] - Rust "minimal runtime" as a priority feature - 
https://www.rust-lang.org/
[12] - Rust Embedded Community on Github - 
https://github.com/rust-embedded
[13] - Discover - Tutorial for Programming Microcontrollers in 
Rust - https://japaric.github.io/discovery/
[14] - Tock - OS for Microcontrollers in Rust - 
http://www.tockos.org/

I greatly miss many of the nice features of D (modeling power, 
metaprogramming, etc...), but Rust is gaining ground [16] [17], 
and, IMO, has a bright future in the micocontroller world.

[16] - Efficient Code Reuse in Rust - 
https://github.com/rust-lang/rfcs/issues/349
[17] - Procedural Macros in Rust - 
https://github.com/rust-lang/rfcs/blob/master/text/1566-proc-macros.md

Nim [18] may also be a good language for programming 
microcontrollers, but I haven't spend much time on it.

[18] - Nim programming language - http://nim-lang.org/