I have some memory mapped hardware in my arm controller.
I define struct regs to describe the registers and __gshared regs* p to point to the actual address.
I have a loop like: while (p.status==0) {...}

The body of the loop does not touch status and so gdc optimizer does not evaluate status again, resulting to an endless loop. Gcc does the same, unless the variable is defined as volatile.

This is ok in tls variables, but gshared variables are not thread safe. Actually I can see from assembler code that this occurs in all shared variables, like:
__gshared int a=0;
while (a==0) {}
with nothing in the body generates just a jump to itself and the program stops.

Another thread, interrupt or hardware can change a __gshared variable any time, so I think that the evalution should not be optimized away.


Another related question: is there a way to make the pointer p immutable but leave the data mutable? The pointer is always set to the fixed address of the hardware, but making the pointer const makes also the data immutable.

On 06-12-2012 19:28, Timo Sintonen wrote:
> I have some memory mapped hardware in my arm controller.
> I define struct regs to describe the registers and __gshared regs* p to
> point to the actual address.
> I have a loop like: while (p.status==0) {...}
>
> The body of the loop does not touch status and so gdc optimizer does not
> evaluate status again, resulting to an endless loop. Gcc does the same,
> unless the variable is defined as volatile.
>
> This is ok in tls variables, but gshared variables are not thread safe.
> Actually I can see from assembler code that this occurs in all shared
> variables, like:
> __gshared int a=0;
> while (a==0) {}
> with nothing in the body generates just a jump to itself and the program
> stops.
>
> Another thread, interrupt or hardware can change a __gshared variable
> any time, so I think that the evalution should not be optimized away.

Yes, the compiler *must* assume that anything __gshared is implicitly volatile in the C sense.

Please file an issue: http://gdcproject.org/bugzilla/

>
>
> Another related question: is there a way to make the pointer p immutable
> but leave the data mutable? The pointer is always set to the fixed
> address of the hardware, but making the pointer const makes also the
> data immutable.

Not with D's type system, since type qualifiers are transitive.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 6 December 2012 18:30, Alex Rønne Petersen <alex@lycus.org> wrote:
> On 06-12-2012 19:28, Timo Sintonen wrote:
>>
>> I have some memory mapped hardware in my arm controller.
>> I define struct regs to describe the registers and __gshared regs* p to
>> point to the actual address.
>> I have a loop like: while (p.status==0) {...}
>>
>> The body of the loop does not touch status and so gdc optimizer does not evaluate status again, resulting to an endless loop. Gcc does the same, unless the variable is defined as volatile.
>>
>> This is ok in tls variables, but gshared variables are not thread safe.
>> Actually I can see from assembler code that this occurs in all shared
>> variables, like:
>> __gshared int a=0;
>> while (a==0) {}
>> with nothing in the body generates just a jump to itself and the program
>> stops.
>>
>> Another thread, interrupt or hardware can change a __gshared variable any time, so I think that the evalution should not be optimized away.
>
>
> Yes, the compiler *must* assume that anything __gshared is implicitly volatile in the C sense.
>

Is this going off your word or mine.... I know as a fact gdc marks shared decls as volatile, but not __gshared.  This was brought into question once when I pointed it out to you, are you now in agreement?


Regards,
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 06-12-2012 19:38, Iain Buclaw wrote:
> On 6 December 2012 18:30, Alex Rønne Petersen <alex@lycus.org> wrote:
>> On 06-12-2012 19:28, Timo Sintonen wrote:
>>>
>>> I have some memory mapped hardware in my arm controller.
>>> I define struct regs to describe the registers and __gshared regs* p to
>>> point to the actual address.
>>> I have a loop like: while (p.status==0) {...}
>>>
>>> The body of the loop does not touch status and so gdc optimizer does not
>>> evaluate status again, resulting to an endless loop. Gcc does the same,
>>> unless the variable is defined as volatile.
>>>
>>> This is ok in tls variables, but gshared variables are not thread safe.
>>> Actually I can see from assembler code that this occurs in all shared
>>> variables, like:
>>> __gshared int a=0;
>>> while (a==0) {}
>>> with nothing in the body generates just a jump to itself and the program
>>> stops.
>>>
>>> Another thread, interrupt or hardware can change a __gshared variable
>>> any time, so I think that the evalution should not be optimized away.
>>
>>
>> Yes, the compiler *must* assume that anything __gshared is implicitly
>> volatile in the C sense.
>>
>
> Is this going off your word or mine.... I know as a fact gdc marks
> shared decls as volatile, but not __gshared.  This was brought into
> question once when I pointed it out to you, are you now in agreement?
>
>
> Regards,
>

I think it was shared declarations that I didn't think needed volatile, but __gshared definitely does (I think Walter agrees on the latter too, not sure about the former).

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org