D.gnu - While optimization and gshared data
- Timo Sintonen (21/21) Dec 06 2012 I have some memory mapped hardware in my arm controller.
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (9/29) Dec 06 2012 Yes, the compiler *must* assume that anything __gshared is implicitly
- Iain Buclaw (8/31) Dec 06 2012 Is this going off your word or mine.... I know as a fact gdc marks
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (8/39) Dec 06 2012 I think it was shared declarations that I didn't think needed volatile,
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
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
On 6 December 2012 18:30, Alex R=F8nne Petersen <alex lycus.org> wrote:On 06-12-2012 19:28, Timo Sintonen wrote: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';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.
Dec 06 2012
=?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> On 06-12-2012 19:38, Iain Buclaw wrote:On 6 December 2012 18:30, Alex Rønne Petersen <alex lycus.org> wrote: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.orgOn 06-12-2012 19:28, Timo Sintonen wrote: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 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.
Dec 06 2012