> 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'.
