> From: Bernd Jendrissek > Sent: Friday, May 05, 2006 12:50 AM [...] > Systems programmers should know better than to expect a particular > implementation of volatile. :) > > How, for example, would you suggest GCC generate code for this? > > volatile int qwerty; > > void p() > { > printf("qwerty = %d\n", ++qwerty); > } > > You could get a (uniprocessor non-interruptible) single-instruction > incl qwerty > but then you'd have to read the value again to be able to print it: > movl %eax, qwerty > at which point you've lost your "one evaluation is one read cycle" > semantics which some people might find even more important than > (uniprocessor!) atomicity. > > Don't forget that if you really wanted SMP-safe modification of > volatiles you'd have to use the "lock" prefix too.
All good points, and I agree. I just mentioned this idea, because GCC is choosing the single instruction memory to memory form in some situations, and I was surprised that it chose this form in the non-volatile case, because it made more sense to me to prefer it in the volatile case - if it were to prefer it all in one situation over another. The current GCC main branch compiler offers a new rendition of the generated code at -O2: movl jv, %eax addl $1, j addl $1, %eax movl %eax, jv where, when incrmenting the non-volatile 'j', it chosses 'addl' over 'incl'.