On 2/1/15 8:41 PM, Joakim wrote:
> 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.

OK, did so. Thanks! -- Andrei

On Monday, 2 February 2015 at 16:55:59 UTC, Andrei Alexandrescu wrote:

> I think it's time to reopen that negotiation.
+1

> So does the argument boil down to better inlining control and enforcement? -- Andrei

If we reopen this I think we should start at the beginning and not yet concentrate implementation details. The discussion should not be developers against users. Developers make things _for_ users. If this was a commercial product, lack of listening users needs would be fatal to the company.


The examples so far have been around a single register. There are single registers in 8 bit processors. Modern 32 bit processors have register banks that have tens of registers, 32 bit each. They are accessed trough structs that may contain arrays, substructs etc. It would be better that the solution we will choose would apply to the whole structure and transitively to all its members.

An example that is tyipcal in real use
1 regs.ctrl |= 0x20;  // select some mode
2 regs.ctrl |= 0x1000; // transmitter on
3 foreach ( b ; buf ) // send a buffer of bytes
  {
4   while ((regs.status & 0x40) ==0) {}  // wait that the transmitter is ready
5   regs.data = b;  // send the byte
  }
6 regs.ctrl &= ~0x20; // transmitter off
7 c=regs.data; // look if there is something to receive

In here the regs struc represents the registers of some peripheral
What the compiler thinks? 1 and 2 are removed because 6 will overwrite the variable anyway. 4 may be moved before 3 because status is not changed in the loop. The loop may be removed totally because the last of 5 overwrites the previous anyway. 7 does not read the register because it uses cached data from 5 instead.

I want to use basio operators and language features to access registers, not templates or functions or wrappers. I just hope we have one word, that I will add to the definition of the register struct and then the struct would behave as expected. I do not care if it is a pragma or a keyword or a property or whatever, but it has to be something in the definition and not something I have to type every time I read or write a register.

On 2 February 2015 at 17:43, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/2/15 9:23 AM, Iain Buclaw via Digitalmars-d wrote:
>>
>> That code doesn't work with DMD.
>>
>> http://goo.gl/hgsHg0
>
>
> Has that been filed yet? -- Andrei
>

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

On 02/02/2015 12:56 PM, Timo Sintonen wrote:
>
> Developers make things _for_ users.

Hear hear, That's a point I always feel deserves far more attention and deliberate, conscious appreciation than it typically gets. (Just a general observation of the overall software development world, not necessarily specific to this discussion.)

> If this
> was a commercial product, lack of listening users needs would be fatal
> to the company.
>

Man do I wish that really was true. It's likely true for a lot of small businesses, but the corporate big dogs can and regularly do get by fine without listening :( That's the power of oligopoly and mindshare.

Am Mon, 02 Feb 2015 12:39:28 -0500
schrieb Steven Schveighoffer <schveiguy@yahoo.com>:

> On 2/2/15 12:06 PM, Johannes Pfau wrote:
> > Am Mon, 02 Feb 2015 02:49:48 -0800
> > schrieb Walter Bright <newshound2@digitalmars.com>:
> 
> >> Please try it before deciding it does not work.
> >
> > I guess one ad hominem wasn't enough?
> 
> Sorry, I'm not really vested in this discussion at all, but I don't think you realize what ad hominem means.
> 
> http://en.wikipedia.org/wiki/Ad_hominem
> 
> -Steve
> 

Ad hominem literally means 'to the person'. en/wikipedia reduces that to character but other definitions (de/wikipedia) include all arguments against a person instead of to the content of the arguments.

Walter implicitly doubted my qualification in his last reply by claiming I don't understand how intrinsics work. Here he basically said I didn't even try to run the code and just making up issues. He's essentially saying I'm dishonest. He didn't respond to the content of my arguments. This is clearly not an argument, it's an attack on my reputation. So how is this not ad hominem?

On 2/2/2015 6:43 AM, Manu via Digitalmars-d wrote:
> I'm pretty sure the only controversy is that you want it to be a
> pragma, everyone else wants it to be an attribute.

That's correct.

My reasoning is simple - an attribute defines the semantics of the interface, a pragma gives instructions to the compiler, and does not affect logical semantics.

For example, attributes change the name mangling, because it affects the semantic interface. A pragma would not.

On 2/2/2015 6:58 AM, Manu via Digitalmars-d wrote:
> They need to be wrapped to be useful,

Wrapping them is a subjective matter of taste.

And before anyone says I don't know what I'm talking about, I used to write embedded systems software. :-)

On 2/2/2015 9:15 AM, Johannes Pfau wrote:
> It's also necessary that the compiler
> knows after inlining that the address is a literal. Loading data from
> fixed literal addresses produces different, more efficient code than
> loading from an runtime address. As the function code will generally be
> written for runtime values the compiler must optimize after inlining
> to recognize the inlined code deals with literals.


  import core.bitop;
  uint test() {
    return volatileLoad(cast(uint *)0x1234);
  }
  ---
  dmd -c foo
  ---
  _D3foo4testFZkL:
        mov     EAX,01234h
        mov     EAX,[EAX]
        ret

Note that was an unoptimized build.

On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Feb 02, 2015 at 08:55:59AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 2/2/15 8:42 AM, Johannes Pfau wrote:
>>> Again the problem is not volatileLoad/Store which
>>> translate to single instructions it's wrappers.
>>
>> So does the argument boil down to better inlining control and
>> enforcement?  -- Andrei
>
> FWIW, from the POV of a bystander, the point is that force-inline for
> certain things (namely wrappers around certain intrinsics, like operator
> overloads for atomics, what-have-you) is necessary in order to guarantee
> that function call overhead will not be incurred no matter what.
>
> Walter seems to dislike forced inlining for various reasons, preferring
> inlining as a hint at the most, and he probably has a point in most
> cases (let the compiler make the judgment). But in other cases, such as
> the one in question, the user needs to override the compiler's decision.
> Currently there's no way to do that, and it's a showstopper for those
> users.

This is a settled issue. After all, I wrote:

http://wiki.dlang.org/DIP56


> Unless we're proposing to flood the compiler with intrinsics, one for
> every possible operator overload of volatile loads/stores, which I think
> should be obviously infeasible. And even then, you still might miss one
> or two other obscure wrappers that users might discover that they need.
> It seems reasonable that instead of burdening the compiler (and compiler
> maintainers, and porters) to keep up with an ever-expanding set of
> intrinsics, making use of the language to express what is needed via
> forced-inline functions is a better way to do things.

I agree that adding more language features instead of inline control is wrong.

Am Mon, 02 Feb 2015 13:15:13 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 2/2/2015 9:15 AM, Johannes Pfau wrote:
> > It's also necessary that the compiler
> > knows after inlining that the address is a literal. Loading data
> > from fixed literal addresses produces different, more efficient
> > code than loading from an runtime address. As the function code
> > will generally be written for runtime values the compiler must
> > optimize after inlining to recognize the inlined code deals with
> > literals.
> 
> 
>    import core.bitop;
>    uint test() {
>      return volatileLoad(cast(uint *)0x1234);
>    }
>    ---
>    dmd -c foo
>    ---
>    _D3foo4testFZkL:
>          mov     EAX,01234h
>          mov     EAX,[EAX]
>          ret
> 
> Note that was an unoptimized build.

What's your argument?
That it still generates 2 instructions in the simplest case? That's an
X86 specific detail. On ARM and other RISC architectures there is a
difference between loading a literal (code into the instruction) or
loading a runtime value. On AVR gcc can even rewrite bit-sized stores
into set-bit and loads into read-bit instructions, but it needs to
know the addresses at compile time. If you don't believe me get an
AVR/ARM compiler and try it.