D in MPLAB FOR PIC32

[Iain Buclaw via Digitalmars-d]

On 7 January 2017 at 01:39, Mike via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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].
>

No, -betterC is not a dialect, it just tells the compiler not to
generate module info.

Making it also mean to tell the compiler not to generate any RTTI
would be an improvement, but then you have every runtime function
depending on RTTI. :-)

Iain