February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | 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
|
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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.
|
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | "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. |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | "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! |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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.
|
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
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.
|
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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. |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to weaselcat | 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. |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | 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. |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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.
|
Copyright © 1999-2021 by the D Language Foundation