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


> * force inlining

http://wiki.dlang.org/DIP56 (Note the author!)


> * (way to omit copy constructor function / force inline)

I don't know what that means

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
>
>
>> * 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


>> * (way to omit copy constructor function / force inline)
>
>
> I don't know what that means

@disable this(this);  ?

I'll let Johannes clarify.


Iain

On Wednesday, 16 July 2014 at 20:11:22 UTC, Johannes Pfau wrote:
> I think it's kinda ridiculous that D embedded code will only be usable
> with strong optimization flags, but whatever.

Do you have numbers? Transitive volatility implies you planned to do very complex things in embedded. If optimizations are so critical, how do you know if complex code can work without them due to its sheer complexity even if typeinfos were removed somehow?

On Wednesday, 16 July 2014 at 20:14:38 UTC, Johannes Pfau wrote:
> I'll take this as you pre-approve all the mentioned extensions?
>
> * way to disable typeinfo for struct

BTW, typeinfos are needed for basic types too and not everything is inline - e.g. array comparison.

> * way to disable initializer
> * force inlining
> * (way to omit copy constructor function / force inline)

We have bugzilla for issues and you can refer to them (with appropriate severity) to describe a level of support for embedded (and baremetal). Would be better with numbers to justify severity.

On Wednesday, 16 July 2014 at 20:14:38 UTC, Johannes Pfau wrote:
> * way to disable typeinfo for struct
> * way to disable initializer
> * force inlining
> * (way to omit copy constructor function / force inline)

BTW, can't lto already remove this unused data? LDC inlines simple initializers already, so they are likely to end up unused (same for functions which where inlined).

On Wed, 16 Jul 2014 11:49:21 -0700, Walter Bright wrote:

> 
> I'll add that if it turns out we can't do a wrapper because of some limitations/bugs in D's expressiveness, that is the problem with D we need to fix, not adding another type modifier.
> 
> It all comes down to leverage. Making user defined types more capable
> has far,
> far more productive leverage than welding specifics into the compiler.

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).

"Iain Buclaw via Digitalmars-d"  wrote in message news:mailman.4214.1405521071.2907.digitalmars-d@puremagic.com...

> No they don't.  Intrinsics make things worse.

? At worst they're useless.

> > They are _trivial_ to implement for any of the compilers.
>
> No they aren't, unless you are talking specifically about volatile.,
> in which case, that depends...

Yes I'm talking about the peek/poke intrinsics.  As all D backends are C backends, and C supports these semantics already...

> Hardware access is supposed to be correct, not performant.

Ideally both! 

On 7/15/14, 9:25 AM, Johannes Pfau wrote:
> DIP62 describes how to solve this problem and make embedded programming
> a first-class citizen in D:
> http://wiki.dlang.org/DIP62
[snip]

The good:

This is a very crisply-written and comprehensive proposal. It could use a little work (e.g. define the typing relationships among volatile, other qualifiers, and unqualified if any) but completeness is outstanding.

The bad:

I think we should reject this proposal. Moreover, the comprehensiveness of the DIP gives me confidence to assess that no amount of work on the proposal could take it to acceptance.

The ugly:

There's none! Actually there's some nice stuff: we could use a bunch of this proposal to specify alternative approaches such as peek/poke.

=============

My rationale:

* I reject he premise ("The volatile qualifier is often used for embedded programming in C/C++[1]".) At most I agree with "often" as in "you'll see at least one use of volatile in some, maybe many, embedded programs" but not "volatile is present many times in a typical embedded application". Hardware/firmware providers often focus on giving access to low-level hardware facilities by using classic encapsulation and exposing APIs, as opposed to just publishing the raw addresses of various ports. Furthermore, the link given as a justification (http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword) is not support for the statement in text, but instead a mere description of volatile, which is also technically incorrect (viz. the use of volatile with threads).

* "volatile" has been one of the most awkward parts of the C and C++ specifications. If we're to learn of anything about it, it's we must stay away from it. It is extremely heavy for what it provides.

* Currently C++ defines observable behavior as "reads and writes of volatile variables and sequences of calls to certain library functions". There is only a small burden associated with sequences of function calls, but the volatile parts are complicating the specification enormously. We'd be better off specifying sequences of calls to functions as defined behavior.

* Adding qualifiers is heavy for the language definition and implementation. Probably they're the most impactful artifact to add.

* Transitivity is only partially justified. For immutable and shared data, transitivity is motivated by code access patterns that chase pointers, but for volatile data there's no hardware reality reflected by transitivity: MMIO only pertains simple address ranges, not node-based volatile structures. The justification in section "Transitivity" is valid but puts undue emphasis on obscure interrupt service routines; even C doesn't go that far (instead it just limits the functions such routines may call).

* The DIP is correct in mentioning that "volatility" is a property of the memory location so it should apply to the respective variable's type, as opposed to just letting the variable have a regular type and then unsafely relying on calls to e.g. peek and poke. But here's a practicality argument that's been already mentioned - such volatile data is rare and classic encapsulation techniques can be applied to it.

* The scalability aspect should be emphasized: a large system may have more need to synchronize threads or to characterize parts of it as functional (pure + immutable). In contrast, a large embedded system does not manifest a proportionally larger presence of volatile data.

==============

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".

Clearly an approach that adds a qualifier would have superior abstraction capabilities, but my experience with C++ (both specification and use) has been that the weight to power ratio of volatile is enormous.


Andrei

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?

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.

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.


Andrei