H1 2015 Priorities and Bare-Metal Programming

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Sun Feb 1 09:21:53 PST 2015


On 1 February 2015 at 16:32, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> On 1 February 2015 at 16:22, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at 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.


More information about the Digitalmars-d mailing list