On Sunday, 1 February 2015 at 23:41:22 UTC, Andrei Alexandrescu wrote:
> 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.

Yes, this needs to be emphasized, as it isn't obvious that you limited it only to stuff that you and Walter can personally enable.  Perhaps you can expand the wiki page with a section for stuff that you two would like to see, but cannot personally enable.  Historically, the D community has been horrible at communicating goals like this, with all current efforts buried in miles of mailing list threads that few outsiders are ever going to wade through, if that.

By putting these goals on the wiki, even if you can't personally enable them, someone might see a goal, decide they'd like to have that too, and start working on it, secure in the knowledge that it's wanted and is likely to be merged if certain quality standards are met.

I suggest you add another clearly labeled section with such goals, what you "would like to see happen" but cannot "work on and make happen."  The community might pick those up and run with them without you.

On 2/1/2015 8:35 PM, Mike wrote:
> 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.

Another problem I forgot to mention is someone would inevitably try to link together a single thread build with a multi thread build, and then would be flummoxed by the problems it caused.

Just go with __gshared.

"Walter Bright"  wrote in message news:mam6qe$15nu$1@digitalmars.com... 

> > We also need a pragma(address) to complement pragma(mangle).
> 
> What would that do?

It would allow naming a memory address, similar to using .org in assembly.

eg
pragma(address, 0x0025)
shared ubyte PORTB;
static assert(&PORTB == cast(ubyte*)0x0025);

This is a much nicer version of C's
#define PORTB (*(volatile unsigned char *)0x0025)

On 2/1/2015 9:21 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:mam6qe$15nu$1@digitalmars.com...
>> > We also need a pragma(address) to complement pragma(mangle).
>>
>> What would that do?
>
> It would allow naming a memory address, similar to using .org in assembly.
>
> eg
> pragma(address, 0x0025)
> shared ubyte PORTB;
> static assert(&PORTB == cast(ubyte*)0x0025);
>
> This is a much nicer version of C's
> #define PORTB (*(volatile unsigned char *)0x0025)

That's what I suspected :-)

  struct Ports {
    static ubyte B() { return volatileLoad(cast(ubyte *)0x0025); }
    static void B(ubyte value) { volatileStore(cast(ubyte *)0x0025, value); }
  }

  ...
  Ports.B = 7;
  foo(Ports.B);

gets the job done. Of course, you could take it further and make a template out of it:

  auto Ports = Port!(ubyte, 0x0025);

On Sunday, 1 February 2015 at 23:41:22 UTC, Andrei Alexandrescu wrote:
> 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.

Added to Wiki.

On 2 Feb 2015 05:50, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 2/1/2015 9:21 PM, Daniel Murphy wrote:
>>
>> "Walter Bright"  wrote in message news:mam6qe$15nu$1@digitalmars.com...
>>>
>>> > We also need a pragma(address) to complement pragma(mangle).
>>>
>>> What would that do?
>>
>>
>> It would allow naming a memory address, similar to using .org in
assembly.
>>
>> eg
>> pragma(address, 0x0025)
>> shared ubyte PORTB;
>> static assert(&PORTB == cast(ubyte*)0x0025);
>>
>> This is a much nicer version of C's
>> #define PORTB (*(volatile unsigned char *)0x0025)
>
>
> That's what I suspected :-)
>
>   struct Ports {
>     static ubyte B() { return volatileLoad(cast(ubyte *)0x0025); }
>     static void B(ubyte value) { volatileStore(cast(ubyte *)0x0025,
value); }
>   }
>
>   ...
>   Ports.B = 7;
>   foo(Ports.B);
>
> gets the job done. Of course, you could take it further and make a
template out of it:
>

Where is the @property?  :)

Iain.

On 2/1/2015 11:16 PM, Iain Buclaw via Digitalmars-d wrote:
> Where is the @property?  :)

yeah, yeah !!

Am Sun, 01 Feb 2015 13:45:24 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 2/1/2015 3:22 AM, Johannes Pfau wrote:
> > Am Sun, 01 Feb 2015 02:11:42 -0800
> > schrieb Walter Bright <newshound2@digitalmars.com>:
> >> 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.
> >
> > I think everybody agreed that these low-level primitives can't be used in end-user code.
> 
> I apparently missed that discussion. (In any case, dealing with memory mapped I/O is not a usual programming task, I expect a programmer doing it will be more sophisticated.)

You keep saying that, but it's simply not true. It's a common task when programming microcontrollers. And people working on microcontrollers are often electrical engineers. Programming beginner courses in EE teach almost nothing, especially not why volatile is necessary or how it propagates with pointers etc. Usually those people just don't use volatile as long as their code works. Once it breaks they add volatile everywhere till it works again.

> 
> > We can generate nice wrappers (nicer than C code),
> > which perform as well as C code, but only with force-inline _and_
> > enabled optimizations (we essentially need heavy constant folding).
> 
> The compiler intrinsics participate in all optimizations.

Not sure what that's supposed to mean. The backend can generate
more efficient code if it knows that an address is a literal value. If
you add wrappers (void f(void* p) {volatileLoad(p)}) the information
that p is a constant is a literal is lost and needs to be recovered
by the backend, which is only done with enabled backend optimizations.

Am Sun, 01 Feb 2015 21:48:40 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 2/1/2015 9:21 PM, Daniel Murphy wrote:
> > "Walter Bright"  wrote in message news:mam6qe$15nu$1@digitalmars.com...
> >> > We also need a pragma(address) to complement pragma(mangle).
> >>
> >> What would that do?
> >
> > It would allow naming a memory address, similar to using .org in assembly.
> >
> > eg
> > pragma(address, 0x0025)
> > shared ubyte PORTB;
> > static assert(&PORTB == cast(ubyte*)0x0025);
> >
> > This is a much nicer version of C's
> > #define PORTB (*(volatile unsigned char *)0x0025)
> 
> That's what I suspected :-)
> 
>    struct Ports {
>      static ubyte B() { return volatileLoad(cast(ubyte *)0x0025); }
>      static void B(ubyte value) { volatileStore(cast(ubyte *)0x0025,
> value); } }
> 
>    ...
>    Ports.B = 7;
>    foo(Ports.B);
> 
> gets the job done.

No, it doesn't even come close.

* Ports.B += 7 doesn't work. In order to implement it you need a
  Volatile!ubyte wrapper, return by ref and avoid some compiler bugs
* You do need force-inline to produce halfway decent code
* You also need to enable backend optimization to produce decent code


This has been discussed before and the best way to express this in the
language is
@property ref @attribute("inlineonly") Volatile!ubyte PORTB() {return
cast((Volatile!ubyte)*)(0x0025)}

You need cross-module inlining, a way to avoid actually generating a callable function (inlineonly =/= forceinline) to avoid bloat and optimization must be enabled. Cross-module inlining is not supported in GDC and not trivial to implement. Also the code looks ugly.

pragma address is:
* Easy to implement
  (https://github.com/D-Programming-microD/GDC/commit/a4027b6d9c53a186c142244553861af8cce5492f)
* A logical, consistent paradigm (if there are extern variables with
  specific names, why no variables with specific address) and extension
  of pragma(mangle)
* Easy to use
* Enforces that the address is a compile time constant, produce perfect
  ASM code even without optimization
* No need to define a wrapper function, with all the consequences that
  hack requires (inlineonly)
* Apparently already in other languages

Given that we can implement pragmas as compiler backend vendors the bar to include pragmas into dmd also shouldn't be too high. Otherwise it'll just be implemented as a compiler dependent pragma.

On 2/2/2015 1:24 AM, Johannes Pfau wrote:
> Usually those people just don't use
> volatile as long as their code works. Once it breaks they add volatile
> everywhere till it works again.

Having a volatile type is not going to make things better for such people. In fact, it may make things worse. It's harder to muck up volatileLoad() and volatileStore().


>> The compiler intrinsics participate in all optimizations.
> Not sure what that's supposed to mean. The backend can generate
> more efficient code if it knows that an address is a literal value. If
> you add wrappers (void f(void* p) {volatileLoad(p)}) the information
> that p is a constant is a literal is lost and needs to be recovered
> by the backend, which is only done with enabled backend optimizations.

Please try it before deciding it does not work.