On 2/1/2015 3:28 AM, Johannes Pfau wrote:
> He got some very direct responses that told him that if an OS doesn't
> have thread-support etc there's no use to run D on that. Responses like
> that obviously demotivate people.

From myself or Andrei? I don't recall such.

There's nothing inherent to D or druntime that requires a multithreaded operating system. After all, a single threaded OS is a multithreaded operating system that simply returns an error when a call to create a new thread is initiated.


> IIRC he also proposed moving more of TypeInfo implementation to the
> runtime so TypeInfo layout can be modified by the runtime or even
> completely avoided by not implementing it in the runtime. The main
> response was that it complicates compiler code too much for little
> benefit. Obviously bare-metal programmers might disagree on the little
> benefit part and as Mike points out rust seems to do similar things.

We did something similar with the GC info, i.e. RTinfo. I think the same technique could be use for TypeInfo.

On 2/1/2015 5:05 AM, Mike wrote:
> On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote:
>>
>> I don't recall what you've suggested in this vein that was very unpopular -
>> can you please post an example?
>
> These are not in any particular order.  They are just how I remember them.

Thanks for doing this. This is great material. I'll respond more in depth later.

On Sunday, 1 February 2015 at 21:47:26 UTC, Walter Bright wrote:
> On 2/1/2015 3:29 AM, weaselcat wrote:
>> On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau wrote:
>>> which perform as well as C code, but only with force-inline
>>
>> why is this still not part of the language? I'm not sure of anything else that
>> has been repeatedly asked for without any good counterarguments.
>
> Because http://wiki.dlang.org/DIP56 generated nothing but controversy.

It is not really the best wording with "many people disagreed with what I wanted and I didn't consider anything else"

On 1 Feb 2015 21:55, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 2/1/2015 8:32 AM, Iain Buclaw via Digitalmars-d wrote:
>>
>> Only if optimisation passes removes the promise the compiler gives to the user.  I'll have to check whether or not the proposed implementation in gdc is even viable vs. having a 'C volatile' type.
>
>
> dmd actually translates those intrinsics into "volatile" C accesses. I
presume gdc and ldc could do the same.
>

For whatever reason, the PR I've got used artificial functions to solve the problem.  Volatile accesses should work, it's just an implementers note to remember to propagate volatile from type to expression, and don't forget to mark it as having side effects.

The work you have to do just to prevent the compiler from optimising. :)

On 2/1/15 1:57 PM, Walter Bright wrote:
> On 2/1/2015 3:28 AM, Johannes Pfau wrote:
>> He got some very direct responses that told him that if an OS doesn't
>> have thread-support etc there's no use to run D on that. Responses like
>> that obviously demotivate people.
>
>  From myself or Andrei? I don't recall such.

Yah, I must chime in here. I'm a bit surprised by Mike's conclusion that he's been rejected.

I assume Mike is Michael V. Franklin who gave the talk at https://www.youtube.com/watch?v=o5m0m_ZG9e8. I think that's an awesome talk and awesome work.

Now when I saw his list of grievances today, I was bummed that it didn't include a bunch of stuff that I can act on. It's just not my specialty, and I can't spread myself too thin. I know Walter is a good match for that, and I'm glad he acted on it.

There's something we need to explain about the vision document itself. Do I want to see more of Mike's awesome work in D going forward? Yes. Do I want to see D on mobile? Of course. There's a lot of stuff that Walter and I would like to see happen that's not in the document. The document itself includes things that he and I actually believe we can work on and make happen. (In the case of vibe.d, we made sure we asked Sönke.) It doesn't include awesome things that others can do without our help - and it shouldn't.

The vision document also doesn't include things we believe are implied. For example "D should remain an efficient, systems-level language." To the extent D prevents systems-level work from getting done, we should fix it to allow that to happen. Again, I'm glad folks like Walter and Iain have an eye on that.


Andrei

On 2/1/2015 2:35 PM, Dicebot wrote:
> On Sunday, 1 February 2015 at 21:47:26 UTC, Walter Bright wrote:
>> On 2/1/2015 3:29 AM, weaselcat wrote:
>>> On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau wrote:
>>>> which perform as well as C code, but only with force-inline
>>>
>>> why is this still not part of the language? I'm not sure of anything else that
>>> has been repeatedly asked for without any good counterarguments.
>>
>> Because http://wiki.dlang.org/DIP56 generated nothing but controversy.
>
> It is not really the best wording with "many people disagreed with what I wanted
> and I didn't consider anything else"

Not agreeing with something != not considering it

On Sunday, 1 February 2015 at 21:58:19 UTC, Walter Bright wrote:

> There's nothing inherent to D or druntime that requires a multithreaded operating system. After all, a single threaded OS is a multithreaded operating system that simply returns an error when a call to create a new thread is initiated.

Agreed, but in the current druntime implementation, by the time the program reaches main, 2 threads have already been initiated.  There is also some runtime and code-size overhead with TLS, even if one is building a single-threaded executable.  I need to look into this in more detail though before I start spouting ideas.  But I certainly welcome the dialogue.

>> IIRC he also proposed moving more of TypeInfo implementation to the
>> runtime so TypeInfo layout can be modified by the runtime or even
>> completely avoided by not implementing it in the runtime. The main
>> response was that it complicates compiler code too much for little
>> benefit. Obviously bare-metal programmers might disagree on the little
>> benefit part and as Mike points out rust seems to do similar things.
>
> We did something similar with the GC info, i.e. RTinfo. I think the same technique could be use for TypeInfo.

I think Adam may have it right with Issue 12270 [1].  But I reject the notion that TypeInfo is a baked-in feature of the language, and if one want to eat the oatmeal cookie, they have to eat the raisins too.

Mike

[1] -  Move TypeInfo to the D Runtime - https://issues.dlang.org/show_bug.cgi?id=12270

On Sunday, 1 February 2015 at 23:41:22 UTC, Andrei Alexandrescu wrote:

> Yah, I must chime in here. I'm a bit surprised by Mike's conclusion that he's been rejected.

Forgive me if that's the conclusion I conveyed.  I said my ideas were unpopular, and if one follows the links to the threads I posted, you'll see that indeed they are.  They were indeed criticized, but it is the lack of interest that is most discouraging.  I don't necessarily feel rejected.  Rather, I see that D is heavily biased towards a few specific domains, and I think D has more potential than that.  So, I suggest the stewards of the language guard against any trend to make the language too domain- or platform-specific.

I also said at the start of this thread that I'm ok with abandoning my ideas, as long as the core team expresses interest and a way forward that I can get on board with.

> I assume Mike is Michael V. Franklin who gave the talk at https://www.youtube.com/watch?v=o5m0m_ZG9e8.

Actually, I was so excited about D, I changed my name to Michael D. Franklin:  https://archive.org/details/dconf2014-day02-talk07

> There's a lot of stuff that Walter and I would like to see happen that's not in the document. The document itself includes things that he and I actually believe we can work on and make happen. (In the case of vibe.d, we made sure we asked Sönke.) It doesn't include awesome things that others can do without our help - and it shouldn't.
>
> The vision document also doesn't include things we believe are implied. For example "D should remain an efficient, systems-level language." To the extent D prevents systems-level work from getting done, we should fix it to allow that to happen. Again, I'm glad folks like Walter and Iain have an eye on that.

This is exactly the information I hoped to elicit in this thread.  If there is interest in hardware programming, let's discuss a way forward.  If the core team already has its hands full, that's fine too.  Perhaps, it's best for me to reallocate myself elsewhere and revisit D at a later time.  But I don't want to remain on the fence.

Mike

On 2/1/2015 4:05 PM, Mike wrote:
> Agreed, but in the current druntime implementation, by the time the program
> reaches main, 2 threads have already been initiated. There is also some runtime
> and code-size overhead with TLS, even if one is building a single-threaded
> executable.  I need to look into this in more detail though before I start
> spouting ideas. But I certainly welcome the dialogue.

You can use __gshared to not get TLS, and a freestanding implementation doesn't necessarily imply no threads.

Back in C land, I have some experience in making code that is buildable for both single and multi thread. The result wasn't worth it (bugs and complexity) - it was far better to always build for multi thread and have a runtime adapt itself for single thread dynamically.

On Monday, 2 February 2015 at 01:17:52 UTC, Walter Bright wrote:

> You can use __gshared to not get TLS,

Yes, that is what we are doing.

> and a freestanding implementation doesn't necessarily imply no threads.

Indeed.

There are also interrupt service routines that can be thought of
as short lived threads.  But the overhead of TLS is not
appropriate for an ISR that demands low latency.  `shared`, on
the other hand, might be more appropriate.  Perhaps a compiler
error should be emitted if an ISR attempts to access state not
decorated with `shared`.  But then the language needs some way to
identify ISRs, yes?

> it was far better to always build for multi thread and have a runtime adapt itself for single thread dynamically.

I'm with you, but if the runtime port only supports a single
thread, I don't want to force users of my libraries to have to
decorate their state with __gshared, as it's redundant.  They
should be able to use the idiomatic D they see in D's learning
material.  Perhaps I can solve this in my runtime implementation
and/or linker scripts, but I need to study the implementation
more.

Mike