www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What is the state of Microcontroller support in d?

reply Taylor Hillegeist <taylorh140 gmail.com> writes:
So, for me one of the greatest things about d is that it is 
compiled to machine language. But It makes me sad that this 
strength doesn't seem to be available in one of the most obvious 
places.

There are some projects:

minilibd:
https://bitbucket.org/timosi/minlibd
The example code is still waiting for decision what is the proper 
way to
access peripheral registers in D code.

The Discovery board Demo:
https://github.com/JinShil/stm32f42_discovery_demo
I actually was able to run the code on this board.

These are very cool, I do notice that both of these use GDC.

The discovery demo looked tedious to implement 
(https://github.com/JinShil/stm32_datasheet_to_d).

I cheated and used a CMSIS .svd file to build the peripherals 
registers.
https://www.keil.com/pack/doc/CMSIS/SVD/html/svd__outline_pg.html

There are big hurdles:
Typeinfo bloat.
Register/Linker file configuation.
Standardized build environments.
More complete runtimes with examples :)
better documentation on d runtime and what is needed for x 
functionality.

But bottom line is it really isn't easy to do. I follow the 
examples for the most part. I feel like the Build environment was 
clunkly for micros and dub certainly was not the right build tool.

I was just curious what is the story?

I know its a goal that in time the community would love to reach.
Apr 07 2016
parent reply Dan Walmsley <dan walms.co.uk> writes:
On Friday, 8 April 2016 at 03:38:01 UTC, Taylor Hillegeist wrote:
 So, for me one of the greatest things about d is that it is 
 compiled to machine language. But It makes me sad that this 
 strength doesn't seem to be available in one of the most 
 obvious places.

 [...]
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?,
Jun 19 2017
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote:
 On Friday, 8 April 2016 at 03:38:01 UTC, Taylor Hillegeist 
 wrote:
 So, for me one of the greatest things about d is that it is 
 compiled to machine language. But It makes me sad that this 
 strength doesn't seem to be available in one of the most 
 obvious places.

 [...]
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?,
I suggest you talk to Mike: http://forum.dlang.org/post/dnrgylliwwmpzggiipek forum.dlang.org He'll fill you in. Also, Radu has been tinkering with microcontrollers using ldc: https://github.com/ldc-developers/ldc/issues/2058
Jun 19 2017
prev sibling next sibling parent reply Mike <none none.com> writes:
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
Jun 20 2017
next sibling parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
 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
How about creating a fork and calling it "SystemD or EmbeddedD" just 1 compiler (LDC probably), do you think its realistic idea? I was so hopeful for D when I saw how nice the syntax is, I saw rust and I didn't get the same feeling, not that I wont give it a chance, I just feel as you know embedded systems is dominated by C and C++ and D seems closer to those than Rust. To be fair I was impressed with the -betterC flag and that actually looks nice I you just want a C replacement but no classes, etc. I have not been able to get even a minimal project to compile when a class is introduced `Error: Missing class declaration: TypeInfo_AssociativeArray` Will take a look at rust, but would be keen to know if you could be motivated by the SystemD / EmbeddedD idea?
Jun 20 2017
next sibling parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 08:48:05 UTC, Dan Walmsley wrote:
 On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
 [...]
How about creating a fork and calling it "SystemD or EmbeddedD" just 1 compiler (LDC probably), do you think its realistic idea? [...]
Regarding not being able to --gc-sections, perhaps this was fixed in LDC? http://forum.dlang.org/post/cxjubpxxknlkqvdgyibj forum.dlang.org
Jun 20 2017
parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 08:54:01 UTC, Dan Walmsley wrote:
 Regarding not being able to --gc-sections, perhaps this was 
 fixed in LDC?
 http://forum.dlang.org/post/cxjubpxxknlkqvdgyibj forum.dlang.org
My last test with LDC is here: https://issues.dlang.org/show_bug.cgi?id=14758#c14 Try to get that code to compile with LDC and let me know what `objdump -s -j .rodata test` gives you. Mike
Jun 20 2017
parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 09:36:54 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 08:54:01 UTC, Dan Walmsley wrote:
 Regarding not being able to --gc-sections, perhaps this was 
 fixed in LDC?
 http://forum.dlang.org/post/cxjubpxxknlkqvdgyibj forum.dlang.org
My last test with LDC is here: https://issues.dlang.org/show_bug.cgi?id=14758#c14 Try to get that code to compile with LDC and let me know what `objdump -s -j .rodata test` gives you. Mike
No longer compiles: "Error: Missing class declaration: ModuleInfo Please check that object.di is included and valid" So I add ` struct ModuleInfo { } ` but then ldc crashes... added an issue here: https://github.com/ldc-developers/ldc/issues/2174
Jun 20 2017
parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 09:46:13 UTC, Dan Walmsley wrote:

 No longer compiles:

 "Error: Missing class declaration: ModuleInfo
 but then ldc crashes...
I had to use code from my minimal runtime experiment here and merge it with some of the code in the TypeInfo bloat issue. Here's code that compiles. object.d https://dpaste.dzfl.pl/f7496296301a test.d https://dpaste.dzfl.pl/6a97b6f7fccf How to compile ------------------------------- `ldc2 --version` LDC - the LLVM D compiler (1.2.0): based on DMD v2.072.2 and LLVM 4.0.0 built with DMD64 D Compiler v2.074.0 Default target: x86_64-unknown-linux-gnu `ldc2 -m64 -defaultlib= -debuglib= -conf= -betterC -release object.d test.d -oftest` `objdump -s -j .rodata test` test: file format elf64-x86-64 Contents of section .rodata: 4005fd 74657374 2e546573 74436c61 73733100 test.TestClass1. 40060d 74657374 2e546573 74436c61 73733200 test.TestClass2. 40061d 74657374 2e546573 74436c61 73733300 test.TestClass3. 40062d 74657374 2e546573 74436c61 73733400 test.TestClass4. 40063d 74657374 2e546573 74436c61 73733500 test.TestClass5. 40064d 74657374 2e546573 74436c61 73733600 test.TestClass6. 40065d 74657374 2e546573 74436c61 73733700 test.TestClass7. 40066d 74657374 2e546573 74436c61 73733800 test.TestClass8. 40067d 74657374 2e546573 74436c61 73733900 test.TestClass9. 40068d 48656c6c 6f0a006f 626a6563 742e4f62 Hello..object.Ob 40069d 6a656374 006f626a 6563742e 54797065 ject.object.Type 4006ad 496e666f 00547970 65496e66 6f5f5374 Info.TypeInfo_St 4006bd 72756374 00547970 65496e66 6f5f436c ruct.TypeInfo_Cl 4006cd 61737300 54797065 496e666f 5f456e75 ass.TypeInfo_Enu 4006dd 6d005479 7065496e 666f5f43 6f6e7374 m.TypeInfo_Const 4006ed 006f626a 6563742e 4572726f 7200 .object.Error. RESULT ------ * The TypeInfo bloat problem still exists. * The problem is even worse as you now have to add even more silly hacks and stubs to get a build. This problem has been known for more than 3 years, and it's only getting worse. Move on. There are better alternatives. Mike
Jun 20 2017
parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:

 I had to use code from my minimal runtime experiment here
Sorry, I forgot to add the link for my minimal runtime experiment: https://github.com/JinShil/minimal_druntime_experiment Mike
Jun 20 2017
parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 10:41:10 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:

 I had to use code from my minimal runtime experiment here
Sorry, I forgot to add the link for my minimal runtime experiment: https://github.com/JinShil/minimal_druntime_experiment Mike
Mike, I think good news: I built a slightly different example, because I don't have access to the linker you have, I just had the arm-none-eabi one and I used ldc 1.3.0-beta2. I compiled using these flags: -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g -defaultlib= -conf= -oftest -better and I got 0 rodata no rtti (I did do -gc-sections) if I don't gc-sections it complains about loads of missing runtime stuff. I tried then to instantiate a class, but it just crashes in hardfault: final abstract class TestClass1 { } final abstract class TestClass2 { } final abstract class TestClass3 { } final abstract class TestClass4 { } final abstract class TestClass5 { } final abstract class TestClass6 { } final abstract class TestClass7 { } final abstract class TestClass8 { } final abstract class TestClass9 { } extern (C) void _d_callfinalizer (void *p) { } class Point { this (int x, int y) { X = x; Y = y; } int X; int Y; } void Main() { scope p = new Point(2,2); p.X = 1; p.Y = 1; int x = 0; x++; } Perhaps D needs to be aware of my stack? I will take a look at your linker script. But at least there is 0 type info data after -gc-sections has run.
Jun 20 2017
next sibling parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote:
 On Tuesday, 20 June 2017 at 10:41:10 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:

 I had to use code from my minimal runtime experiment here
Sorry, I forgot to add the link for my minimal runtime experiment: https://github.com/JinShil/minimal_druntime_experiment Mike
Mike, I think good news: I built a slightly different example, because I don't have access to the linker you have, I just had the arm-none-eabi one and I used ldc 1.3.0-beta2. I compiled using these flags: -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g -defaultlib= -conf= -oftest -better and I got 0 rodata no rtti (I did do -gc-sections) if I don't gc-sections it complains about loads of missing runtime stuff. I tried then to instantiate a class, but it just crashes in hardfault: final abstract class TestClass1 { } final abstract class TestClass2 { } final abstract class TestClass3 { } final abstract class TestClass4 { } final abstract class TestClass5 { } final abstract class TestClass6 { } final abstract class TestClass7 { } final abstract class TestClass8 { } final abstract class TestClass9 { } extern (C) void _d_callfinalizer (void *p) { } class Point { this (int x, int y) { X = x; Y = y; } int X; int Y; } void Main() { scope p = new Point(2,2); p.X = 1; p.Y = 1; int x = 0; x++; } Perhaps D needs to be aware of my stack? I will take a look at your linker script. But at least there is 0 type info data after -gc-sections has run.
Actually about the stack was a red herring the code did actually work! my only issue is now when I add a method I get: C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv': C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind' Whats the invariant object thing?
Jun 20 2017
parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote:

 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
 `_D4main5Point3SumMFZi':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference 
 to `_D9invariant12_d_invariantFC6ObjectZv'
 C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference 
 to `_d_assert_msg'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
 `_D4main4MainFZv':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference 
 to `_d_eh_resume_unwind'

 Whats the invariant object thing?
Please publish your source code and your linker script.
Jun 20 2017
next sibling parent Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote:

 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
 `_D4main5Point3SumMFZi':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined 
 reference to `_D9invariant12_d_invariantFC6ObjectZv'
 C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined 
 reference to `_d_assert_msg'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
 `_D4main4MainFZv':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined 
 reference to `_d_eh_resume_unwind'

 Whats the invariant object thing?
Please publish your source code and your linker script.
I'm going to shove it in a GitHub repo give me 10 mins.
Jun 20 2017
prev sibling parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote:

 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
 `_D4main5Point3SumMFZi':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined 
 reference to `_D9invariant12_d_invariantFC6ObjectZv'
 C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined 
 reference to `_d_assert_msg'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
 `_D4main4MainFZv':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined 
 reference to `_d_eh_resume_unwind'

 Whats the invariant object thing?
Please publish your source code and your linker script.
https://github.com/vitalElement/STM32DBlinky
Jun 20 2017
next sibling parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote:

 https://github.com/vitalElement/STM32DBlinky
I don't see the linker script
Jun 20 2017
parent Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 12:00:28 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote:

 https://github.com/vitalElement/STM32DBlinky
I don't see the linker script
sorry, committed linker script now :)
Jun 20 2017
prev sibling parent Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote:
 On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote:

 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In 
 function `_D4main5Point3SumMFZi':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined 
 reference to `_D9invariant12_d_invariantFC6ObjectZv'
 C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined 
 reference to `_d_assert_msg'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In 
 function `_D4main4MainFZv':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined 
 reference to `_d_eh_resume_unwind'

 Whats the invariant object thing?
Please publish your source code and your linker script.
https://github.com/vitalElement/STM32DBlinky
commands to build were: Compile: ldc2 -c -O0 -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g -debuglib= -conf= -oftest -betterC -release main.d -ofmain.o ldc2 -c -O0 -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g -debuglib= -conf= -oftest -betterC -release stm32f4xx_startup.d -ofstm32f4xx_startup.o Link: arm-none-eabi-gcc -mcpu=cortex-m4 -Wl,-Map,output.map -nostdlib -mfpu=fpv4-sp-d16 -mfloat-abi=hard -nostartfiles -Wl,--gc-sections -O0 -Wl,-T"link.ld" -oBlinky.elf attribute.o object.o main.o stm32f4xx_startup.o -Wl,--start-group -Wl,--end-group If you need windows binaries for arm-none-eabi I can give you some.
Jun 20 2017
prev sibling parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote:

 I think good news:
The bloat is still there, but for some reason it's in the .text section. `objdump -s -j .text test` ... 80004a8 9efe80bd 80b5fff7 9afe80bd 80b5fff7 ................ 80004b8 96fe80bd 80b5fff7 92fe80bd 80b5fff7 ................ 80004c8 8efe80bd 80b5fff7 71feffe7 00200028 ........q.... .( 80004d8 02d1ffe7 ffe7f9e7 80bd6d61 696e2e54 ..........main.T 80004e8 65737443 6c617373 31006d61 696e2e54 estClass1.main.T 80004f8 65737443 6c617373 32006d61 696e2e54 estClass2.main.T 8000508 65737443 6c617373 33006d61 696e2e54 estClass3.main.T 8000518 65737443 6c617373 34006d61 696e2e54 estClass4.main.T 8000528 65737443 6c617373 35006d61 696e2e54 estClass5.main.T 8000538 65737443 6c617373 36006d61 696e2e54 estClass6.main.T 8000548 65737443 6c617373 37006d61 696e2e54 estClass7.main.T 8000558 65737443 6c617373 38006d61 696e2e54 estClass8.main.T 8000568 65737443 6c617373 39006865 6c6c6f0d estClass9.hello. 8000578 0a000000
Jun 20 2017
parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 12:22:42 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote:

[...]
The bloat is still there, but for some reason it's in the .text section. [...]
damn! If we push to have this fixed after that we are pretty close to having something usable are we not?
Jun 20 2017
parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:

 If we push to have this fixed after that we are pretty close to 
 having something usable are we not?
Depends on your definition of "usable". Fixing the bloat issue would remove a current road block, and at least allow progress to continue. IMO, to make D a pleasant experience on the ARM Cortex-M platform, we'll need to implement the entire druntime including threading, GC, exceptions, dynamic arrays, etc... even if those features are not used. This is because D just hasn't been designed and implemented in a modular fashion to allow one to pay-as-they-go, and as you experienced in one of your other posts today, you just get too many undefined references and other odd errors that have nothing to do with your code. The only way to make those errors go away is to ensure everything in druntime is there. If the bloat problem were solved, we could at least continue working towards that end. But it's not immediately apparent to me how much overhead a complete runtime implementation will add to as simple microcontroller application, and how well the compiler and linker can optimize and remove that overhead. We may encounter other roadblocks like I did with the TypeInfo bloat, and have to fight a major battle to get something done about it. But I don't want to have to implement the entire druntime in order to start making progress. It shouldn't have to be that way. Mike
Jun 20 2017
next sibling parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:

 If we push to have this fixed after that we are pretty close 
 to having something usable are we not?
Depends on your definition of "usable". Fixing the bloat issue would remove a current road block, and at least allow progress to continue. IMO, to make D a pleasant experience on the ARM Cortex-M platform, we'll need to implement the entire druntime including threading, GC, exceptions, dynamic arrays, etc... even if those features are not used. This is because D just hasn't been designed and implemented in a modular fashion to allow one to pay-as-they-go, and as you experienced in one of your other posts today, you just get too many undefined references and other odd errors that have nothing to do with your code. The only way to make those errors go away is to ensure everything in druntime is there. If the bloat problem were solved, we could at least continue working towards that end. But it's not immediately apparent to me how much overhead a complete runtime implementation will add to as simple microcontroller application, and how well the compiler and linker can optimize and remove that overhead. We may encounter other roadblocks like I did with the TypeInfo bloat, and have to fight a major battle to get something done about it. But I don't want to have to implement the entire druntime in order to start making progress. It shouldn't have to be that way. Mike
I completely agree with you here, its a real shame! Id be happy to put some effort into this, I don't know if you can help me put pressure on the right people to get the bloat thing fixed. It seems like its probably fixed in dmd compiler, but none of the others. I think ldc2 is the compiler that has the most potential because it can easily be compiled unlike the gdc one and then dmd one doesn't seem to support arm out the box unless things changed recently. I'm happy to have a GC on a system like stm32, as I read it only collects on calls to new, and most sensible embedded designs would just allocate at initialization and not during runtime. Threading I think we could easily use freertos or something underneath. Which just leaves dynamic arrays and exceptions which I know next to nothing about right now :) Firstly who do we need to talk to about the bloat in LDC?
Jun 20 2017
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 20 June 2017 at 14:12:36 UTC, Dan Walmsley wrote:
 Firstly who do we need to talk to about the bloat in LDC?
I'll be happy to help with the LDC stuff once I hand in my Honours thesis on the 3rd of July, just ask on https://gitter.im/ldc-developers/main or send me a message on gitter.
Jun 21 2017
parent reply Dan Walmsley <dan walms.co.uk> writes:
On Wednesday, 21 June 2017 at 08:38:21 UTC, Nicholas Wilson wrote:
 On Tuesday, 20 June 2017 at 14:12:36 UTC, Dan Walmsley wrote:
 Firstly who do we need to talk to about the bloat in LDC?
I'll be happy to help with the LDC stuff once I hand in my Honours thesis on the 3rd of July, just ask on https://gitter.im/ldc-developers/main or send me a message on gitter.
whats your gitter handle?
Jun 21 2017
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 21 June 2017 at 09:12:56 UTC, Dan Walmsley wrote:
 On Wednesday, 21 June 2017 at 08:38:21 UTC, Nicholas Wilson 
 wrote:
 On Tuesday, 20 June 2017 at 14:12:36 UTC, Dan Walmsley wrote:
 Firstly who do we need to talk to about the bloat in LDC?
I'll be happy to help with the LDC stuff once I hand in my Honours thesis on the 3rd of July, just ask on https://gitter.im/ldc-developers/main or send me a message on gitter.
whats your gitter handle?
thewilsonator
Jun 21 2017
prev sibling next sibling parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:

 [...]
Depends on your definition of "usable". Fixing the bloat issue would remove a current road block, and at least allow progress to continue. [...]
Mike, I was thinking if you had used memory mapped structs instead of classes you probably wouldn't have come up across the rtti bloat so hard and it although be annoying wouldn't have been a show stopper, was there a particular reason to use classes to represent the registers? Dan
Jun 20 2017
parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 22:31:15 UTC, Dan Walmsley wrote:

 Mike, I was thinking if you had used memory mapped structs 
 instead of classes you probably wouldn't have come up across 
 the rtti bloat so hard and it although be annoying wouldn't 
 have been a show stopper, was there a particular reason to use 
 classes to represent the registers?
I was able to work around the problem without having to compromise on my programming by compiling to assembly, modifying the assembly with this sed hack [1], and compiling the assembly to object code. This masked the problem from me and my users, and I didn't have to change any of my code. It's always possible to find something that will work, especially in a comprehensive language like D and a rich tools like ld, binutils, and Linux-in-general. But I can't go to my employer, colleagues, and customers with an object-oriented language, telling them they should avoid using classes or implement sed hacks in their build script, and expect to be taken seriously. It's fine to do such things for oneself, but my goal was to build a product line like Arduino around D, and I can't expect that to succeed with such blatant flaws in the language implementation. The problem should be fixed. GDC may have fixed the problem recently with [2], but I haven't tested it. Lucia Cojocaru is (was?) also working on addressing the problem by lowering TypeInfo calls in the compiler to templates [3]. I've been meaning to test the GDC changes, but I still have a bad taste in my mouth from my last experience with D, and have trouble getting excited about it like I once was. You seem quite determined to get this to work. With such determination I'm sure you'll find a way. I hope you succeed and find the support you need. Who knows? I may have a change of heart later and join you. Mike [1] - https://github.com/JinShil/stm32f42_discovery_demo/blob/master/build.d#L69 [2] - https://github.com/D-Programming-GDC/GDC/pull/456 [3] - http://dconf.org/2017/talks/cojocaru.html
Jun 20 2017
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 21 June 2017 at 00:08:24 UTC, Mike wrote:
 GDC may have fixed the problem recently with [2], but I haven't 
 tested it.  Lucia Cojocaru is (was?) also working on addressing 
 the problem by lowering TypeInfo calls in the compiler to 
 templates [3].
I've decoupled the code generating compiler (gdc) from runtime (druntime), and will generate pseudo typeinfo if any are missing - this is in contrast to dmd which would complain about missing TypeInfo/corrupt object.d. This should mean that object.d can be distilled down to just: module object; class Object { } From a minilibd perspective, and the compiler will just fill in the blanks and continue without complaint. However you'll still get linker errors if you don't define TypeInfo anywhere. (If there are any other compile-time errors, it's likely the dmd front-end complaining because it can't generate some artificial helper function). Pay-as-you-go TypeInfo generation could be done stemming from this. Currently, the strategy is to always generate TypeInfo in the module that "owns" the type, on premise that although it may not be used itself, some external module may want it. Really though, this is probably about as far as I can push it without making changes to the dmd frontend or druntime library itself. IMO the right thing to do is to not push the compiler, but to push the D runtime library into improving it's runtime interface. i.e: https://github.com/dlang/druntime/pull/1792 Replacing the old legacy functions with templates that don't require typeinfo is the direction that people should be pushing in. Without this, I can't see -fno-rtti being possible without severely restricting users to a slim subset. Regards, Iain.
Jun 21 2017
prev sibling parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:

 IMO, to make D a pleasant experience on the ARM Cortex-M 
 platform, we'll need to implement the entire druntime including 
 threading, GC, exceptions, dynamic arrays, etc... even if those 
 features are not used.  This is because D just hasn't been 
 designed and implemented in a modular fashion to allow one to 
 pay-as-they-go, and as you experienced in one of your other 
 posts today, you just get too many undefined references and 
 other odd errors that have nothing to do with your code.  The 
 only way to make those errors go away is to ensure everything 
 in druntime is there.
The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. Forget -betterC and -no-rtti; embrace it all! We might just be be able to turn this lemon into lemonade afterall. I'm having a bit of a change of heart (or maybe there's something in my coffee). I'll be traveling overseas for the next month, so when I return I'll revisit this and see if it still appeals to me. Mike
Jun 20 2017
next sibling parent Dan Walmsley <dan walms.co.uk> writes:
On Wednesday, 21 June 2017 at 00:50:35 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:

 [...]
The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. Forget -betterC and -no-rtti; embrace it all! We might just be be able to turn this lemon into lemonade afterall. I'm having a bit of a change of heart (or maybe there's something in my coffee). I'll be traveling overseas for the next month, so when I return I'll revisit this and see if it still appeals to me. Mike
When iv been using c++ on stm32 I have had to rely on gcsections to produce a workable binary. Have a good holiday, ill try as much as I can to improve things in the mean time 😀
Jun 21 2017
prev sibling next sibling parent reply Dan Walmsley <dan walms.co.uk> writes:
On Wednesday, 21 June 2017 at 00:50:35 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:

 [...]
The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. [...]
Mike, is there an email address I can contact you outside the forum?
Jun 21 2017
parent Mike <none none.com> writes:
On Wednesday, 21 June 2017 at 08:25:35 UTC, Dan Walmsley wrote:
 Mike, is there an email address I can contact you outside the 
 forum?
"slavo"~"5150"~AT_SYMBOL~"yahoo"~PERIOD~"com";
Jun 21 2017
prev sibling parent reply Russell Haley <russ.haley gmail.com> writes:
On Wednesday, 21 June 2017 at 00:50:35 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:

 [...]
The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. [...]
Hi, I'm new to D. I'm looking at options on microcontrollers and I wondered if anything ever came of this effort? I'm currently using FreeRTOS on a TI CC3220 at work. I also have access to an STM32 board and an NXP K220f (?). Thanks!
Nov 28 2018
next sibling parent welkam <wwwelkam gmail.com> writes:
On Thursday, 29 November 2018 at 06:50:12 UTC, Russell Haley 
wrote:
 Hi, I'm new to D. I'm looking at options on microcontrollers 
 and I wondered if anything ever came of this effort? I'm 
 currently using FreeRTOS on a TI CC3220 at work. I also have 
 access to an STM32 board and an NXP K220f (?).

 Thanks!
Not using runtime at all. Check out betterC https://dlang.org/spec/betterc.html
Nov 29 2018
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 29 November 2018 at 06:50:12 UTC, Russell Haley 
wrote:
 On Wednesday, 21 June 2017 at 00:50:35 UTC, Mike wrote:
 On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:

 [...]
The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. [...]
Hi, I'm new to D. I'm looking at options on microcontrollers and I wondered if anything ever came of this effort? I'm currently using FreeRTOS on a TI CC3220 at work. I also have access to an STM32 board and an NXP K220f (?). Thanks!
You can see the extent of my work at https://github.com/JinShil/stm32f42_discovery_demo I'm afraid that proof of concept is all I've got; sorry. You will likely also be interested in https://bitbucket.org/timosi/minlibd I think it's a more complete port of the D runtime to the ARM Cortex-M platform, but the author of the project will have to give you the details. I'm not sure if it is still being maintained. There was a good push in the last year or so to decouple the runtime from the compiler so one can start bare-metal programming with a C-like subset of D features and incrementally implement features in the runtime. See the changelog for 2.079 for a few details: https://dlang.org/changelog/2.079.0.html#minimal_runtime. There was also work towards getting more features of D working in -betterC. See https://dlang.org/spec/betterc.html I've always hated -betterC though, and affectionately refer to it as -worseD. IMO -betterC would not even be necessary if the compiler<->runtime interface would just get fixed. The fix includes, but is not limited to, removing all of the dependencies on runtime type information (a.k.a. `TypeInfo`) for information the compiler already knows at compile-time. This can be done by lowering expressions to templates instead of `extern "C"` runtime functions calls like these: https://wiki.dlang.org/Runtime_Hooks. It's quite difficult and messy due to D's ` safe, nogc, throw` attribute hell (you'll understand as you get more familiar with D). My last PR working towards that end can be found here: https://github.com/dlang/druntime/pull/2268 I'm no longer working with D, so I don't know if any of this has a future; sorry. Mike
Nov 29 2018
next sibling parent reply Russell Haley <russ.haley gmail.com> writes:
On Thursday, 29 November 2018 at 11:00:45 UTC, Mike Franklin 
wrote:
 On Thursday, 29 November 2018 at 06:50:12 UTC, Russell Haley 
 wrote:
 [...]
You can see the extent of my work at https://github.com/JinShil/stm32f42_discovery_demo I'm afraid that proof of concept is all I've got; sorry. [...]
Thanks for everything you've done! I'm just putting Arch on my Beaglebone Black and I'll look to try out D there and move down the stack again when I get bored. Yay... dd just finished! :) Russ
Dec 10 2018
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 11 December 2018 at 04:37:26 UTC, Russell Haley wrote:

 I'm just putting Arch on my Beaglebone Black and I'll look to 
 try out D there and move down the stack again when I get bored.
If you're interested in ARM Cortex-A for the time being, here are a few resources that might help you: https://wiki.dlang.org/Building_LDC_runtime_libraries http://d-land.sepany.de/tutorials/einplatinenrechner/einstieg-in-die-raspberry-pi-e twicklung-mit-ldc/. It's in German, but it's an easy read with an online translator. A couple of forum discussions that I found interesting: https://forum.dlang.org/post/siznumnaitvcnyqpleeh forum.dlang.org https://forum.dlang.org/post/ppuiojvktlnnvoqfdtuc forum.dlang.org Good luck! Mike
Dec 10 2018
prev sibling parent reply Piotrek <dummy dummy.gov> writes:
On Thursday, 29 November 2018 at 11:00:45 UTC, Mike Franklin 
wrote:
 I'm no longer working with D, so I don't know if any of this 
 has a future; sorry.
Hi Mike, That's really sad information. I was following your contributions and I am really grateful for what you have done for the D development. Especially in the embedded systems area, which is my primary domain. I plan to start/reopen my open source activities in D (specially for SW related to the RISC-V architecture) from January 2019 (yeah, that's correct, the new year's plans ;)). BTW, I was thinking about suggesting a new targeted donation campaign to found a paid work on D improvements in embedded system development. If it's not a problem for you, can you explain what was the reason for leaving D? Cheers, Piotrek
Dec 11 2018
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 11 December 2018 at 18:08:10 UTC, Piotrek wrote:

 That's really sad information.
Well, it's also not entirely true. I've submitted a few pull requests recently to hopefully help clear a few obstacles for others. But after that I probably won't be doing besides a few things here and there.
 If it's not a problem for you, can you explain what was the 
 reason for leaving D?
I don't want to get too deep into it, as I don't think it will result in anything positive. Suffice it to say, I want to get to X. I don't know where others want to go, but it sure doesn't look like they're all that interested in X. I don't think I'll ever be able to use D professionally if it stays on the current trajectory, and trying to influence its direction by contributing is exhausting and affects me negatively. At one point I asked myself: "In 5 years what will I have to show for the blood, sweat, and tears I put into D?" vs "In 5 years what will I have to show for the sweat, without the blood and tears, I put into X?". Opportunity cost is the term that comes to mind. Even if X never materializes I'll be more skilled, fulfilled, and ultimately happier if I work on X than contribute to D. Mike
Dec 11 2018
next sibling parent reply Jusl <jusl gmail.usa> writes:
On Wednesday, 12 December 2018 at 01:12:51 UTC, Mike Franklin 
wrote:
 I don't think I'll ever be able to use D professionally if it 
 stays on the current trajectory, and trying to influence its 
 direction by contributing is exhausting and affects me 
 negatively.
Yup contributing to D is one of the worst experiences I've had with any Open Source project I've contributed to. Walter isn't even willing to admit to there being problems, if he thinks there isn't a problem then nothing about it will end up changing. Doesn't help that he has opinions that align with that developer from Clojure, that he owes you and everyone else absolutely nothing, yet (I imagine or at the very least *hope*) he wants D to succeed. The two don't go hand in hand though.
Dec 12 2018
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Wednesday, 12 December 2018 at 09:19:51 UTC, Jusl wrote:
 On Wednesday, 12 December 2018 at 01:12:51 UTC, Mike Franklin 
 wrote:
 I don't think I'll ever be able to use D professionally if it 
 stays on the current trajectory, and trying to influence its 
 direction by contributing is exhausting and affects me 
 negatively.
Yup contributing to D is one of the worst experiences I've had with any Open Source project I've contributed to. Walter isn't even willing to admit to there being problems, if he thinks there isn't a problem then nothing about it will end up changing. Doesn't help that he has opinions that align with that developer from Clojure, that he owes you and everyone else absolutely nothing, yet (I imagine or at the very least *hope*) he wants D to succeed. The two don't go hand in hand though.
To clarify, contributing to D, in general, has been a positive experience for me. Many on the team were quite helpful reviewing my PRs, helping me get them right, contributing alternate implementations, helping me with testing and other infrastructure issues, etc. Thank you all for your support. I did my best to pay some of that back; and I'm sorry if it wasn't enough. What I was trying to say is that trying to influence D's direction (by contributing) is exhausting and constantly leaves me feeling disappointed and sad rather than hopeful for the future. I think Walter and Andrei have set a course for where they want to go, and aren't all that interested in alternatives. That's fine, and if I were leading the project, I wouldn't have it any other way, but I don't think the current direction will be successful (I'd be delighted to be proven wrong). I see the next 5 years much like the past 5 years, and that's discouraging to me. I have no hard feelings for those I worked with when I was more actively involved. I salute you all and thank you for your support. I just have a different vision for what D should be; that's all. Mike
Dec 12 2018
parent Radu <void null.pt> writes:
On Wednesday, 12 December 2018 at 11:13:01 UTC, Mike Franklin 
wrote:
 On Wednesday, 12 December 2018 at 09:19:51 UTC, Jusl wrote:
 On Wednesday, 12 December 2018 at 01:12:51 UTC, Mike Franklin 
 wrote:
 I don't think I'll ever be able to use D professionally if it 
 stays on the current trajectory, and trying to influence its 
 direction by contributing is exhausting and affects me 
 negatively.
Yup contributing to D is one of the worst experiences I've had with any Open Source project I've contributed to. Walter isn't even willing to admit to there being problems, if he thinks there isn't a problem then nothing about it will end up changing. Doesn't help that he has opinions that align with that developer from Clojure, that he owes you and everyone else absolutely nothing, yet (I imagine or at the very least *hope*) he wants D to succeed. The two don't go hand in hand though.
To clarify, contributing to D, in general, has been a positive experience for me. Many on the team were quite helpful reviewing my PRs, helping me get them right, contributing alternate implementations, helping me with testing and other infrastructure issues, etc. Thank you all for your support. I did my best to pay some of that back; and I'm sorry if it wasn't enough. What I was trying to say is that trying to influence D's direction (by contributing) is exhausting and constantly leaves me feeling disappointed and sad rather than hopeful for the future. I think Walter and Andrei have set a course for where they want to go, and aren't all that interested in alternatives. That's fine, and if I were leading the project, I wouldn't have it any other way, but I don't think the current direction will be successful (I'd be delighted to be proven wrong). I see the next 5 years much like the past 5 years, and that's discouraging to me. I have no hard feelings for those I worked with when I was more actively involved. I salute you all and thank you for your support. I just have a different vision for what D should be; that's all. Mike
Mike, thanks for contributing to D! Hope that you might reconsider and keep adding your great experience to making D a viable tool for embedded devices. I think I understand your frustration, I glanced over some of your PRs and your comments and I think you were right on many occasions. It is a shame that some times W&A don't properly reward talent and expertise. Time to time we see talented people giving up and leaving because some friction with W or A. I wish there was a way to mediate such things. All the best, Radu
Dec 13 2018
prev sibling parent welkam <wwwelkam gmail.com> writes:
On Wednesday, 12 December 2018 at 09:19:51 UTC, Jusl wrote:
 Yup contributing to D is one of the worst experiences I've had
Could you email me with PR that went south so I could look at it?
 Walter isn't even willing to admit to there being problems
Citation needed https://www.youtube.com/watch?v=iXNE00Cnaqk Actually first sentence in Clojure thread was admission of it being an issue[1].
 Doesn't help that he has opinions that align with that 
 developer from Clojure
Where did you got that impression from? Walter and other people here are not people person. They can work on silicone based systems for months but if they had to work with carbon based life form systems they would get exhausted after a day. Thats why things are the way they are 1 https://forum.dlang.org/thread/ptkmgq$8o8$1 digitalmars.com?page=1
Dec 12 2018
prev sibling parent Piotrek <dummy dummy.gov> writes:
On Wednesday, 12 December 2018 at 01:12:51 UTC, Mike Franklin 
wrote:
 Well, it's also not entirely true.  I've submitted a few pull 
 requests recently to hopefully help clear a few obstacles for 
 others.  But after that I probably won't be doing besides a few 
 things here and there.
I'm glad to hear you will be around. Be it only sharing your great experience in the forums :) We have here too few people with the embedded programming on their mind.
 I don't want to get too deep into it, as I don't think it will 
 result in anything positive.  Suffice it to say, I want to get 
 to X.  I don't know where others want to go, but it sure 
 doesn't look like they're all that interested in X.  I don't 
 think I'll ever be able to use D professionally if it stays on 
 the current trajectory, and trying to influence its direction 
 by contributing is exhausting and affects me negatively.
I know what you mean by the problems of using D in the industry. On the other hand, 2 years ago I heard about a small company in my area (Poland) that uses D for automation/robotics projects. It was a little surprise to me. And to be honest sometimes it's just a matter of the company management and/or technical leaders' preferences if D can be used in production. And I have seen so much bad tools and technologies (not related to D) used in embedded systems area. And no one cared about it. As for Walter and Andrei, they have different priorities. And that's ok for me, because I know that embedded system industry is very though place for new technologies. Still, D can be already used in micro controllers if requirements don't rule it out.
 At one point I asked myself:  "In 5 years what will I have to 
 show for the blood, sweat, and tears I put into D?" vs "In 5 
 years what will I have to show for the sweat, without the blood 
 and tears, I put into X?".  Opportunity cost is the term that 
 comes to mind.  Even if X never materializes I'll be more 
 skilled, fulfilled, and ultimately happier if I work on X than 
 contribute to D.
Yeah, I agree that we all should make our bets based on clean conscience in order to not regret it. And maybe it's time for you to have some fun and refill your energy. As for me, I still consider D to be the best option for embedded systems. The only contender is Rust. But in my opinion (based on my experience) it has too many serious disadvantages and bad goals. To keep it short. I hope, that if there are any D related activities done by you they will be fruitful for all parties. I can say, I learnt many things from you. So,thank you. BTW, is there a way I can send you some $ for a beer? :) Like donation button? Cheers, Piotrek
Dec 12 2018
prev sibling parent Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 08:48:05 UTC, Dan Walmsley wrote:

 How about creating a fork and calling it "SystemD or EmbeddedD" 
 just 1 compiler (LDC probably), do you think its realistic idea?
It would take a very dedicated and talented individual, or a small team of talent to do that. I'm not that individual, and there doesn't seem to be much interest from the D community to pull it off, IMO.
 I was so hopeful for D when I saw how nice the syntax is, I saw 
 rust and I didn't get the same feeling, not that I wont give it 
 a chance, I just feel as you know embedded systems is dominated 
 by C and C++ and D seems closer to those than Rust.
I had the same initial reaction to Rust, and still do to some extent. Rust does not have the modeling power and efficient code reuse that D does. D allows you to write code the way you think about it. Rust requires you to change the way you think about your code. But D requires too many silly hacks and compromises just to get a build that works. Rust allows you to incrementally build up your system (pay-as-you-go) without any nonsense. Despite my criticism, I think D has much more potential than Rust, I just don't think it will ever be realized without a fork.
 To be fair I was impressed with the -betterC flag and that 
 actually looks nice I you just want a C replacement but no 
 classes, etc.
If -betterC were ever fully implemented it would indeed be a "Better C", but it would also be a "Worse D" and I'd be forever disappointed that I couldn't individually pay for the features I wanted.
 I have not been able to get even a minimal project to compile 
 when a class is introduced

 `Error: Missing class declaration: TypeInfo_AssociativeArray`
Stick with only structs until you get it working, then you can tackle classes.
 Will take a look at rust, but would be keen to know if you 
 could be motivated by the SystemD / EmbeddedD idea?
It would be a huge tangent from what I really want to do and would require a different skill set than what I currently possess. While I'm confident that I could acquire the necessary skills to pull it off, I only have the resources to contribute to such an endeavor on a part-time basis. It's not something I can do right now. I want to program machines that interface with the physical world. I don't really want to have to build my own custom toolchain to do it (But I wouldn't mind contributing to one). Rust is also slowly improving, and if some of their RFCs ever get implemented, it will obtain much more modeling power like D. That's where I'm placing my bets at the moment. Mike
Jun 20 2017
prev sibling next sibling parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
 On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote:
 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.
offtopic: How do you see the future comparing D and Rust? Are you enjoying Rust?
Jun 20 2017
parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 08:52:20 UTC, Wulfklaue wrote:

  offtopic: How do you see the future comparing D and Rust? Are 
 you enjoying Rust?
I'm not enjoying Rust; I just believe it is currently better than D and has a better future. As I stated in my previous posts, Rust does not have the modeling power of D. D allows you to program the way you think, Rust requires you to change the way you think. However, there are a few RFCs and issues that Rust is working through that could change that. I don't see the same kind of progress and discussion happening in D... except today :-) That being said, let me offer a counter-opinion that occurred to me some time ago. Many embedded systems programmers are not software engineers; they are electrical engineers that write code. A "better C" may be exactly what some of these types would like; I'm just not one of them. Mike
Jun 20 2017
parent drug <drug2004 bk.ru> writes:
20.06.2017 12:33, Mike пишет:
 That being said, let me offer a counter-opinion that occurred to me some
 time ago.  Many embedded systems programmers are not software engineers;
 they are electrical engineers that write code.
I'm sure this is very important thing - many who writes code are not software engineers at all. I can't imagine my colleagues switch to Rust, it' impossible because Rust is too hardcore. But I can imagine they switch to D easily. And this is power of D. I've read your posts early and I think you're right, at least at general. I guess dlang should make these changes that allow using D at embedded systems.
Jun 20 2017
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
 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.
The C++ bindings should be opt-in..
  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.
Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause!
 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.
That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time!
Jun 20 2017
parent reply Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 11:11:20 UTC, Seb wrote:
 On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
 [...]
The C++ bindings should be opt-in..
 [...]
Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause!
 [...]
That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time!
I am going to try and get a minimal example working so I can fully evaluated what is needed, and then I will try and submit a DIP.
Jun 20 2017
parent Dan Walmsley <dan walms.co.uk> writes:
On Tuesday, 20 June 2017 at 12:35:38 UTC, Dan Walmsley wrote:
 On Tuesday, 20 June 2017 at 11:11:20 UTC, Seb wrote:
 On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
 [...]
The C++ bindings should be opt-in..
 [...]
Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause!
 [...]
That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time!
I am going to try and get a minimal example working so I can fully evaluated what is needed, and then I will try and submit a DIP.
Ignoring the bloat issue before, any ideas why I might be getting hard fault when trying to create object on the stack?
Jun 20 2017
prev sibling parent Taylor Hillegeist <taylorh140 gmail.com> writes:
On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote:
 On Friday, 8 April 2016 at 03:38:01 UTC, Taylor Hillegeist 
 wrote:
 So, for me one of the greatest things about d is that it is 
 compiled to machine language. But It makes me sad that this 
 strength doesn't seem to be available in one of the most 
 obvious places.

 [...]
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?,
I'm still around I just haven't been working with D for a while. I see you were trying to put an effort together. That's really great, if there is anything I can do to keep the momentum let me know.
Oct 25 2017