www.digitalmars.com         C & C++   DMDScript  

D.gnu - While optimization and gshared data

reply "Timo Sintonen" <t.sintonen luukku.com> writes:
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.
Dec 06 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
Dec 06 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
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
Dec 06 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 December 2012 18:30, Alex R=F8nne 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=3D=3D0) {...}

 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=3D0;
 while (a=3D=3D0) {}
 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, --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Dec 06 2012