This is related to the recent publication of D's H1 2015 Priorities [1], but I suspect this post could create a few tangents, so I decided to post it under its own thread.

IMO D has high potential for kernel programming, embedded systems, and other bare-metal varieties where high-level language features are often not needed or even wanted (but sometimes used).  D has some fantastic features for low-level programming with great power and convenience, but it is currently heavily biased towards platforms with a full-featured, resource abundant operating system, and some of it's high-level features get in the way.  Periodically, users pop into the forum, ask questions this, give it a try, and then leave [2].

There has been the occasional suggestion for a -minimalD compiler flag or some other twist, but IMO that's not a very elegant or appropriate solution.  I think Rust is headed in a better direction with it's "minimal runtime" philosophy [3] and features like #![no_std], #![feature(lang_items)], #[lang = "whatever"], and extern "rust-intrinsic" [4].  I'm not suggesting D mimic Rust's approach, but rather learn from it, and provide an attractive alternative that jives with D's way of doing things.

However, when I read "Foster library additions over language changes, and raise the bar on language changes", I suspect changes to accommodate this kind of programming will be viewed as "shuffling the deck".  So, I'm currently on the fence with D.  Rust and Nim are showing great promise in this domain, Rust has already implemented supporting features (as mentioned above), and Rust's Zinc project [5] is really catching on.

Is D's core team genuinely interested in this domain?

If you are genuinely interested, are you committed?  And if so, what direction would you like to take?  So far, my ideas have been very unpopular and I'm growing weary fighting the current.  How can I contribute in a way that gets us both where we want to go?

If you're not particularly interested in this domain, that's OK.  Perhaps you are interested, but not at this time.  Perhaps you are only interested in mobile and mico-PC platforms that have full-featured operating systems, but not resource constrained bare-metal platforms.  Whatever the case, please let it be known.

Thanks in advance for your constructive comments,

Mike

[1] - 2015 H1 Vision - http://forum.dlang.org/post/majurl$2457$1@digitalmars.com
[2] - Why D is not a Systems Programming Language - https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md
[3] - Rust Programming Language - http://www.rust-lang.org/
[4] - Writing Safe Unsafe and Low-Level Code in Rust - http://doc.rust-lang.org/0.11.0/guide-unsafe.html
[5] - Zinc, the bare metal stack for rust - https://github.com/hackndev/zinc

On Sunday, 1 February 2015 at 05:21:15 UTC, Mike wrote:
> ...
> [2] - Why D is not a Systems Programming Language - https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md

I don't have much to add but this is one of the better critiques of D I've seen.

On 1/31/2015 9:21 PM, Mike wrote:
> Is D's core team genuinely interested in this domain?

Yes.


> If you are genuinely interested, are you committed?  And if so, what direction
> would you like to take?  So far, my ideas have been very unpopular and I'm
> growing weary fighting the current. How can I contribute in a way that gets us
> both where we want to go?

I don't recall what you've suggested in this vein that was very unpopular - can you please post an example?

On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote:
> On 1/31/2015 9:21 PM, Mike wrote:
>> Is D's core team genuinely interested in this domain?
>
> Yes.
>
>
>> If you are genuinely interested, are you committed?  And if so, what direction
>> would you like to take?  So far, my ideas have been very unpopular and I'm
>> growing weary fighting the current. How can I contribute in a way that gets us
>> both where we want to go?
>
> I don't recall what you've suggested in this vein that was very unpopular - can you please post an example?

The one of major issues is: how to access hardware. We need a language feature to access hardware registers. This has been discussed twice. Both time you rejected anything but your own idea of library functions. You rejected anything anybody said. No serious programmer will write code that way. It worked in 80's when we had an uart with three registers 8 bit each. Now an usb or ethernet peripheral may have 100 registers 32 bit each.

There are workarounds:
- disable optimization. the code works but is 3 times bigger and slower
- GDC marks shared variables as volatile. This works mostly but is unstandard and unstable and may be removed at any time.
- Have an separate templated data type which has its own operators. While this seems to work, it is a little complicated way to do things.

----
There are some areas that might be developed.

There are not many people here that work with microcontollers besides Mike and I. Many people make just web services. This is ok, the business is there. If bare metal is a goal for D then it is impostant that we processor people do not feel ourselves as second class people. Our needs and concerns should at least be noticed and respected by leaders.

More practioal thing is the runtime library. Mike, Adam and some others have started with empty runtime and added only what they need. This does not get very far because mamy real D features need runtime functions. I may the only one to start with full runtime and remove anything that does not work. I have many D features working now, like exceptions.

The runtime needs:
- NoSystem should be a supported platform and not a build failure. The build system should leave out files and features that are not available.
- Unrelated things should be split in separate files and unnecessary imports should be removed. Object.d is pulling in most of the library with its imports. Imports that are used only in unittests should be in unittest blocks. I know this is worked on.
- Runtime library functions should not use gc and free all resources they use. I know this is also being worked on.

The absolute minimum set of changes that I had to make can be seen here:
https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default

These are for GDC 2.065 and some of these may have changed when GDC 2.066 is out.
In addition, I still need my own build system to select files and to compile with correct processor options. My skills are not enough to modify the original build system.

On 2/1/2015 1:38 AM, Timo Sintonen wrote:
> The one of major issues is: how to access hardware. We need a language feature
> to access hardware registers. This has been discussed twice. Both time you
> rejected anything but your own idea of library functions. You rejected anything
> anybody said. No serious programmer will write code that way. It worked in 80's
> when we had an uart with three registers 8 bit each. Now an usb or ethernet
> peripheral may have 100 registers 32 bit each.

core.bitop.volatileLoad() and volatileStore() are implemented, and do the job. They are compiler intrinsics that result in single instructions. They support 8, 16, 32 and 64 bit loads and stores.


> There are workarounds:
> - disable optimization. the code works but is 3 times bigger and slower
> - GDC marks shared variables as volatile. This works mostly but is unstandard
> and unstable and may be removed at any time.
> - Have an separate templated data type which has its own operators. While this
> seems to work, it is a little complicated way to do things.

I don't see the need for any of these workarounds. The compiler intrinsics are volatile, i.e. they are not optimized away even when optimization is turned on.


> The runtime needs:
> - NoSystem should be a supported platform and not a build failure. The build
> system should leave out files and features that are not available.
> - Unrelated things should be split in separate files and unnecessary imports
> should be removed. Object.d is pulling in most of the library with its imports.
> Imports that are used only in unittests should be in unittest blocks. I know
> this is worked on.
> - Runtime library functions should not use gc and free all resources they use. I
> know this is also being worked on.
>
> The absolute minimum set of changes that I had to make can be seen here:
> https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default

The link does not work.

I have added https://issues.dlang.org/show_bug.cgi?id=14100 and have also added the "bare-metal" keyword. Please enumerate the issues you're having, file them on bugzilla, and tag them with "bare-metal".

> The absolute minimum set of changes that I had to make can be seen here:
> https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default
>
corrected link (I think):

https://bitbucket.org/timosi/minlibd/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default

On Sunday, 1 February 2015 at 10:11:57 UTC, eles wrote:
>> The absolute minimum set of changes that I had to make can be seen here:
>> https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default
>>
> corrected link (I think):
>
> https://bitbucket.org/timosi/minlibd/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default

And, for info, pasted here:

This file is not a changelog. Instead, this file documents changes
that are needed to the current gdc libdruntime sources.
(2.065 and 4.10 series gdc/gcc)

The files are in the order they were needed when testing

core/stdc/stdlib.d
49  default value for RAND_MAX instead of assert

core/memory
84-85,123 changed private imports to public

gcstub/gc.d
31  removed import stdio
134 removed thread_init

object.d
30         removed import minfo
132-142    removed factory  (moduleinfo is not used)
562        renamed GC.free gc_free (core.memory not used)
604-657    removed associative arrays
858-873    removed module related code
1561-1732  removed moduleinfo
1733-1932  removed monitor
1933-2283  removed assicoative arrays
2257,2262  changed comment to /* */

core/exception.d
14  removed import stdio
593-596,610-613,627-630,639-642 removed module related functions

rt/lifetime.d
246,278,310 removed synchronized
1222-122    removed monitor call

rt/adi.d
46-134  removed _adReverseChar (because utf is not supported)
95-96   changed comment to //
320-360 removed _adSortChar and _adSortWchar because of several
        missing functions
	
	
core/time.d (optional file)
23   removed import stdc.time
24   removed import stdio
2125 dummy retval for the function


PS I have no connection with the OP.

On 2/1/2015 2:12 AM, eles wrote:
> On Sunday, 1 February 2015 at 10:11:57 UTC, eles wrote:
>>> The absolute minimum set of changes that I had to make can be seen here:
>>> https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default
>>>
>>>
>> corrected link (I think):
>>
>> https://bitbucket.org/timosi/minlibd/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default
>>
>
> And, for info, pasted here:
>
> This file is not a changelog. Instead, this file documents changes
> that are needed to the current gdc libdruntime sources.
> (2.065 and 4.10 series gdc/gcc)

Please post to bugzilla and tag the issue with "bare-metal".

On Sunday, 1 February 2015 at 10:14:28 UTC, Walter Bright wrote:

>
> Please post to bugzilla and tag the issue with "bare-metal".

https://issues.dlang.org/show_bug.cgi?id=14101

Please have a look and correct if necessary.

On 2/1/2015 2:21 AM, eles wrote:
> On Sunday, 1 February 2015 at 10:14:28 UTC, Walter Bright wrote:
>
>>
>> Please post to bugzilla and tag the issue with "bare-metal".
>
> https://issues.dlang.org/show_bug.cgi?id=14101
>
> Please have a look and correct if necessary.

Thank you.