On 2/2/2015 1:39 AM, Johannes Pfau wrote:
> No, it doesn't even come close.
>
> * Ports.B += 7 doesn't work.

This should not be done with MMIO because the read and write cycles generated are ill-defined and vary based on obscure backend details.


> In order to implement it you need a
>    Volatile!ubyte wrapper, return by ref and avoid some compiler bugs

What compiler bugs?


> * You do need force-inline to produce halfway decent code

Nope. volatileLoad() and volatileStore() do not produce function calls.


> * You also need to enable backend optimization to produce decent code

Not any more true than with volatile types, because the compiler intrinsic actually translates to a volatile type, not a function call.


You are making a lot of assumptions that volatileLoad() and volatileStore() do not work. Please try it, examine the generated code, and see.

On Monday, 2 February 2015 at 09:22:41 UTC, Walter Bright wrote:
> On 2/1/2015 11:16 PM, Iain Buclaw via Digitalmars-d wrote:
>> Where is the @property?  :)
>
> yeah, yeah !!

BTW, when D's property will finally be cleaned up?...

I did miss something, or there is still a "-property" flag out there?

On 2 February 2015 at 10:57, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/2/2015 1:39 AM, Johannes Pfau wrote:
>>
>> No, it doesn't even come close.
>>
>> * Ports.B += 7 doesn't work.
>
>
> This should not be done with MMIO because the read and write cycles generated are ill-defined and vary based on obscure backend details.
>
>
>> In order to implement it you need a
>>    Volatile!ubyte wrapper, return by ref and avoid some compiler bugs
>
>
> What compiler bugs?
>
>
>> * You do need force-inline to produce halfway decent code
>
>
> Nope. volatileLoad() and volatileStore() do not produce function calls.
>

I think he was referring to ubyte B() and void B(), and not the
load/store intrinsics themselves.

On 2 February 2015 at 07:47, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> 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.

I'm pretty sure the only controversy is that you want it to be a pragma, everyone else wants it to be an attribute. I don't think anyone has argued against a force_inline.

On Monday, 2 February 2015 at 14:43:22 UTC, Manu 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. I don't think
> anyone has argued against a force_inline.

I also support pragma, but didn't agree with proposed semantics (that force_inline doesn't actually force). And Walter completely disagreed with any alternative proposals making any further progress in search of compromise effectively impossible.

On 2 February 2015 at 20:57, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/2/2015 1:39 AM, Johannes Pfau wrote:


>>> * You do need force-inline to produce halfway decent code
>
>
> Nope. volatileLoad() and volatileStore() do not produce function calls.

They need to be wrapped to be useful, and in this case, the wrapping
should not result in function calls either. I have the same problem
with simd intrinsics.
Intrinsics are useless if they are to be wrapped by a function call to
use them in a practical way.

Can we just have this:

pragma(inline) means "inline it unless you literally can't make it work".

pragma(force_inline) or pragma(always_inline) means "the same as pragma(inline), but stop compilation if it can't be inlined".

in the absence of either of these, "inline as you please".


A pragma is OK. It will get the job done. People need something to get the job done. If Walter really doesn't like the attribute route then give his taste the benefit of the doubt and let's move on.

On Monday, 2 February 2015 at 14:43:22 UTC, Manu wrote:
> On 2 February 2015 at 07:47, Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> 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.
>
> I'm pretty sure the only controversy is that you want it to be a
> pragma, everyone else wants it to be an attribute. I don't think
> anyone has argued against a force_inline.

I don't care if it is a pragma or attribute or whatever, it just *needs to exist*.

On 2/2/15 6:55 AM, Dicebot wrote:
> On Monday, 2 February 2015 at 14:43:22 UTC, Manu 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. I don't think
>> anyone has argued against a force_inline.
>
> I also support pragma, but didn't agree with proposed semantics (that
> force_inline doesn't actually force). And Walter completely disagreed
> with any alternative proposals making any further progress in search of
> compromise effectively impossible.

I think it's time to reopen that negotiation. -- Andrei

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

> On 2/2/2015 1:39 AM, Johannes Pfau wrote:
> > No, it doesn't even come close.
> >
> > * Ports.B += 7 doesn't work.
> 
> This should not be done with MMIO because the read and write cycles generated are ill-defined and vary based on obscure backend details.
> 

Operator overloading? If +=7 is implemented as a
volatileLoad + modify  volatileStore as wrapper would your whole point
is void.

> 
> > In order to implement it you need a
> >    Volatile!ubyte wrapper, return by ref and avoid some compiler
> > bugs
> 
> What compiler bugs?
> 
> 
> > * You do need force-inline to produce halfway decent code
> 
> Nope. volatileLoad() and volatileStore() do not produce function
> calls.
> 

This was a reply to your example. Your example used a function which wrapped volatileLoad:

>>> static ubyte B() { return volatileLoad(cast(ubyte *)0x0025); }

I think it's obvious were a force-inline would go.

> 
> > * You also need to enable backend optimization to produce decent code
> 
> Not any more true than with volatile types, because the compiler intrinsic actually translates to a volatile type, not a function call.
>

I've explained that in detail:
https://forum.dlang.org/post/manfpc$2v0u$1@digitalmars.com
I'm not going to explain it again. Also your focus on intrinsics is
wrong, I'm not talking about the intrinsics I'm talking about
wrappers.

> 
> You are making a lot of assumptions that volatileLoad() and
> volatileStore() do not work. Please try it, examine the generated
> code, and see.
> 

Nice ad hominem.

I've implemented volatileLoad/store for GDC long before you implemented
it in DMD. I've written a Volatile!T wrapper, a Register wrapper and a
tool which scrapes datasheets for Register definitions and automatically
generates Register definitions. I've also fixed GDC for 8bit AVR
processors and run and tested D code with volatileLoad/Store on these
processors. Three months ago.
I'm not making any assumptions about how volatileLoad/Store work, I
know it quite well. Again the problem is not volatileLoad/Store which
translate to single instructions it's wrappers. All the points I made
come from experience implementing and using these wrappers.

I don't see any point continuing this discussion as long as you don't take me seriously. At least you could read my replies properly.