RE: codegen differences for increment of a volatile int

["Gary Funck" <gary at intrepid dot com>]

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