On 2/1/15 8:09 AM, Timo Sintonen wrote:
> On Sunday, 1 February 2015 at 15:28:25 UTC, Andrei Alexandrescu wrote:
>> On 2/1/15 1:38 AM, Timo Sintonen wrote:
>>> The one of major issues is: how to access hardware. We need a language
>>> feature to access hardware registers.
>>
>> What features do Rust and Nim provide for such?
>>
>> Andrei
>
> I was not the one who compared the languages and I have never used rust
> or nim.  I just pointed out that d had no way to access registers
> properly. DMD and GDC optimize very heavily and may cache, reorder and
> remove any access they think is not needed.
> Other languages may not have such optimizations and registers can be
> accessed just with normal memory oprations.

How do volatileLoad() and volatileStore() in core.bitop fail to meet such needs? -- Andrei

On 1 February 2015 at 16:22, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/1/15 8:09 AM, Timo Sintonen wrote:
>>
>> On Sunday, 1 February 2015 at 15:28:25 UTC, Andrei Alexandrescu wrote:
>>>
>>> On 2/1/15 1:38 AM, Timo Sintonen wrote:
>>>>
>>>> The one of major issues is: how to access hardware. We need a language feature to access hardware registers.
>>>
>>>
>>> What features do Rust and Nim provide for such?
>>>
>>> Andrei
>>
>>
>> I was not the one who compared the languages and I have never used rust
>> or nim.  I just pointed out that d had no way to access registers
>> properly. DMD and GDC optimize very heavily and may cache, reorder and
>> remove any access they think is not needed.
>> Other languages may not have such optimizations and registers can be
>> accessed just with normal memory oprations.
>
>
> How do volatileLoad() and volatileStore() in core.bitop fail to meet such
> needs? -- Andrei
>
>

Only if optimisation passes removes the promise the compiler gives to the user.  I'll have to check whether or not the proposed implementation in gdc is even viable vs. having a 'C volatile' type.

Iain.

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

> Only if optimisation passes removes the promise the compiler gives to
> the user.  I'll have to check whether or not the proposed
> implementation in gdc is even viable vs. having a 'C volatile' type.

How could it not be?  It's just *(volatile T*)ptr = value; - which gcc ir can obviously express. 

"Andrei Alexandrescu"  wrote in message news:malii6$iho$2@digitalmars.com...

> Interesting. I naïvely believe it would simplify rather than complicate the compiler. -- Andrei

That's what we thought about moving the AA implementation into the library! 

On 1 February 2015 at 16:58, Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> "Iain Buclaw via Digitalmars-d"  wrote in message news:mailman.5711.1422808332.9932.digitalmars-d@puremagic.com...
>
>> Only if optimisation passes removes the promise the compiler gives to the user.  I'll have to check whether or not the proposed implementation in gdc is even viable vs. having a 'C volatile' type.
>
>
> How could it not be?  It's just *(volatile T*)ptr = value; - which gcc ir
> can obviously express.

Depends on how you represent it.  :)

I believe the correct way would be mem_ref[(volatile T*) ptr] = value;

Miss a propagation of volatile or side_effects flag setting though, then *poof* the volatility is gone.

Iain.

On 1 February 2015 at 16:32, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 1 February 2015 at 16:22, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On 2/1/15 8:09 AM, Timo Sintonen wrote:
>>>
>>> On Sunday, 1 February 2015 at 15:28:25 UTC, Andrei Alexandrescu wrote:
>>>>
>>>> On 2/1/15 1:38 AM, Timo Sintonen wrote:
>>>>>
>>>>> The one of major issues is: how to access hardware. We need a language feature to access hardware registers.
>>>>
>>>>
>>>> What features do Rust and Nim provide for such?
>>>>
>>>> Andrei
>>>
>>>
>>> I was not the one who compared the languages and I have never used rust
>>> or nim.  I just pointed out that d had no way to access registers
>>> properly. DMD and GDC optimize very heavily and may cache, reorder and
>>> remove any access they think is not needed.
>>> Other languages may not have such optimizations and registers can be
>>> accessed just with normal memory oprations.
>>
>>
>> How do volatileLoad() and volatileStore() in core.bitop fail to meet such
>> needs? -- Andrei
>>
>>
>
> Only if optimisation passes removes the promise the compiler gives to the user.  I'll have to check whether or not the proposed implementation in gdc is even viable vs. having a 'C volatile' type.
>
> Iain.

I believe the litmus test was to create a library struct Volatile(T) type.

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

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


> We also need a pragma(address) to complement pragma(mangle).

What would that do?


> * Using only part of druntime is ugly. The one thing most people would
>    probably like to strip out is the GC, but keep exception handling,
>    threads, ... But the GC is everywhere: core.demangle doesn't work
>    without, backtraces, exceptions, threads. Right now you either use
>    all of druntime or nothing but it's not possible to use parts of
>    druntime only, it's not modular enough.

De-Modularity is one of those things that one has to continually fight, like mildew in the shower. Turn your back on it for a moment, and interdependence creeps back in.

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.

On 2/1/2015 8:09 AM, Timo Sintonen wrote:
> I just pointed out that d had no way to access registers properly.

volatileLoad() and volatileStore() do the job correctly.


> DMD and GDC
> optimize very heavily and may cache, reorder and remove any access they think is
> not needed.

This is specifically not the case with compiler intrinsics volatileLoad() and volatileStore().


> Other languages may not have such optimizations and registers can be accessed
> just with normal memory oprations.

The trouble with those is when memory mapped registers have specific behaviors based on how and when read/write cycles occur. Many instructions are implicitly read-modify-write, and may not offer sufficient control. volatileLoad() and volatileStore() make the read/write operations and cycles explicit, even in the presence of aggressive optimizations.

On 2/1/2015 8:32 AM, Iain Buclaw via Digitalmars-d wrote:
> Only if optimisation passes removes the promise the compiler gives to
> the user.  I'll have to check whether or not the proposed
> implementation in gdc is even viable vs. having a 'C volatile' type.

dmd actually translates those intrinsics into "volatile" C accesses. I presume gdc and ldc could do the same.