On 17 July 2014 17:16, Sean Kelly via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> We had the volatile statement as a compiler barrier in D1. Why not basically that instead of a type qualifier?  We pretty much need it back for atomics anyway.

I don't recall volatile statements ever working properly, or at least working in an agreed way.

On 7/17/14, 12:15 PM, Iain Buclaw via Digitalmars-d wrote:
> On 17 July 2014 17:16, Sean Kelly via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> We had the volatile statement as a compiler barrier in D1. Why not basically
>> that instead of a type qualifier?  We pretty much need it back for atomics
>> anyway.
>
> I don't recall volatile statements ever working properly, or at least
> working in an agreed way.

And that goes for volatile in C and C++ as well. -- Andrei

On 7/17/2014 9:16 AM, Sean Kelly wrote:
> We had the volatile statement as a compiler barrier in D1. Why not basically
> that instead of a type qualifier?  We pretty much need it back for atomics anyway.

Volatile and atomic semantics are very different, are historically conflated and confused, and I think it's well worth it to use completely distinct mechanisms for both.

Am Thu, 17 Jul 2014 11:43:04 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 7/17/14, 9:06 AM, John Colvin wrote:
> > On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei Alexandrescu wrote:
> >> I think an approach based on functions peek/poke is a lot more promising. D programs must define sequences of std calls anyway, otherwise even the simplest programs that use writeln("What's your name?") followed by a readln() are incorrect. So in a way peek/poke come for "free".
> >
> > Could you expand on this "sequences of calls"? What exactly do you mean by defining it?
> 
> For example if you run this C program:
> 
> printf("ur name: ");
> fflush(stdout);
> scanf("%s", &name);
> printf("Hello, %s!", name);
> 
> it's guaranteed the order of calls is preserved.

Function calls are actually compiler barriers in every C (like) compiler, I guess that's even in the standard. Relying on this too much can be dangerous with inlining though.

Back to topic: Thanks for your response, so let's go with peek/poke / volatileLoad/Store then.

On Thursday, 17 July 2014 at 19:31:25 UTC, Walter Bright wrote:
> On 7/17/2014 9:16 AM, Sean Kelly wrote:
>> We had the volatile statement as a compiler barrier in D1. Why not basically
>> that instead of a type qualifier?  We pretty much need it back for atomics anyway.
>
> Volatile and atomic semantics are very different, are historically conflated and confused, and I think it's well worth it to use completely distinct mechanisms for both.

Fair enough. My point was simply that volatile as defined for D1 seems potentially useful. I certainly liked it for concurrent programming, even if the guarantees it provided were only ever on paper and not actually implemented.

Am Thu, 17 Jul 2014 08:05:33 +0100
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 17 July 2014 07:09, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > On 7/16/2014 1:12 PM, Johannes Pfau wrote:
> >>
> >> I'll take this as you pre-approve all the mentioned extensions?
> >>
> >> * way to disable typeinfo for struct
> >
> >
> > Worth investigating. It'd probably be much more effective to work the linker angle of removing items for which no references exist. Martin was working on that, but his latest attempt had to be reverted, as it needed a new approach.
> >
> >
> >
> >> * way to disable initializer
> >
> >
> > T t = void; // no initialization
I'm referring to the __initZ symbol/data, it gets emitted even if all fields of a struct are =void initialized.

> >
> >
> >> * force inlining
> >
> >
> > http://wiki.dlang.org/DIP56 (Note the author!)
> >
> 
> For the time being, GDC has @attribute("forceinline")
> 
> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d
> 

Yes. We'll have to take a look if we can prevent the function from appearing in the object file (with force inline, there's no need to keep the function, it must always be inlined anyway)

> 
> >> * (way to omit copy constructor function / force inline)
> >
> >
> > I don't know what that means
> 
> @disable this(this);  ?
> 
> I'll let Johannes clarify.
> 

I was referring to the implicitly generated __cpctor not the postblit.
As it's implicitly generated you can't put @force-inline on it.
This applies to all compiler generated functions though,
__fieldPostBlit, __fieldDtor autogenerated opAssign and probably some
more.

However, simple (POD?) types are probably not affected as those don't
get a __cpctor IIRC?

On 17 July 2014 21:01, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Thu, 17 Jul 2014 08:05:33 +0100
> schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:
>
>> On 17 July 2014 07:09, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> > On 7/16/2014 1:12 PM, Johannes Pfau wrote:
>> >>
>> >> I'll take this as you pre-approve all the mentioned extensions?
>> >>
>> >> * way to disable typeinfo for struct
>> >
>> >
>> > Worth investigating. It'd probably be much more effective to work the linker angle of removing items for which no references exist. Martin was working on that, but his latest attempt had to be reverted, as it needed a new approach.
>> >
>> >
>> >
>> >> * way to disable initializer
>> >
>> >
>> > T t = void; // no initialization
> I'm referring to the __initZ symbol/data, it gets emitted even if all fields of a struct are =void initialized.
>
>> >
>> >
>> >> * force inlining
>> >
>> >
>> > http://wiki.dlang.org/DIP56 (Note the author!)
>> >
>>
>> For the time being, GDC has @attribute("forceinline")
>>
>> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d
>>
>
> Yes. We'll have to take a look if we can prevent the function from appearing in the object file (with force inline, there's no need to keep the function, it must always be inlined anyway)
>

Just mark them as extern.  More important, we need a way to build the bodies of functions in other modules for cross-module inlining (needed for @forceinline to work correctly without getting 'function body is not available' errors).

On Thursday, 17 July 2014 at 19:56:23 UTC, Johannes Pfau wrote:
> Am Thu, 17 Jul 2014 11:43:04 -0700
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>
>> On 7/17/14, 9:06 AM, John Colvin wrote:
>> > On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei Alexandrescu
>> > wrote:
>> >> I think an approach based on functions peek/poke is a lot more
>> >> promising. D programs must define sequences of std calls anyway,
>> >> otherwise even the simplest programs that use writeln("What's your
>> >> name?") followed by a readln() are incorrect. So in a way peek/poke
>> >> come for "free".
>> >
>> > Could you expand on this "sequences of calls"? What exactly do you
>> > mean by defining it?
>> 
>> For example if you run this C program:
>> 
>> printf("ur name: ");
>> fflush(stdout);
>> scanf("%s", &name);
>> printf("Hello, %s!", name);
>> 
>> it's guaranteed the order of calls is preserved.

only because rearranging those cannot be proved to create the same observable semantics (in this case of course it can be actively disproved). That doesn't apply to all sequences of function calls, thankfully.

> Function calls are actually compiler barriers in every C (like)
> compiler, I guess that's even in the standard. Relying on this too
> much can be dangerous with inlining though.

As I understand it (I'm not a compiler writer or a C standard expert):

*Opaque* function calls are a compiler memory barrier in C and that's only by necessity (that opaque function could contain a memory barrier, amongst other problems).

If the compiler can guarantee to maintain the same visible semantics of defined behaviour it can rearrange function calls just as freely as anything else.

On Thursday, 17 July 2014 at 20:42:16 UTC, Iain Buclaw via Digitalmars-d wrote:
> Just mark them as extern.  More important, we need a way to build the
> bodies of functions in other modules for cross-module inlining (needed
> for @forceinline to work correctly without getting 'function body is
> not available' errors).

Jernej Krempuš put something together for LDC a while back: https://github.com/jerro/ldc/compare/inlining. Unfortunately, it seems like he never got around to submitting the symbol naming fixes to the upstream frontend.

Cheers,
David

On 07/17/2014 04:01 PM, Byron Heads wrote:
> A Volatile(T) in stdlib seems to make a lot of sense, I am also wondering
> if the implementation of shared should be done the same way (if it does
> already then ignore), just use the compile to enforce shared and have it
> rewrite it as Shared(T).
> ...

I've grepped the DMD source and currently 'shared' is a _bit flag_ set or not set on some uint member field of the 'Type' class. I assume this is also the main reason why adding new type qualifiers is a really unpleasant undertaking: this is a highly non-modular design.