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.

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?,

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

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

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?

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?

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

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

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

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