D in MPLAB FOR PIC32

[tomsmith]

On Sunday, 8 January 2017 at 21:37:41 UTC, Iain Buclaw wrote:
> 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


You can find the controller here

https://www.allicdata.com/list.html?category_id=1900