Re: m68k gcc/egcs question

Zoltan Kocsi <zoltan@bendor.com.au> wrote:
>I've got a few problems with them. One is the code efficiency:


I suggest reporting it as a bug if you have not. See the gcc.gnu.org
website for details. gcc-bugs@gcc.gnu.org is the address.


>In addition, neither gcc nor egcs seem to treat the 'volatile'
>qualifier in any sensible way.


a=b=c means fetch c, store into b, fetch b, store into a. It does not
mean fetch c, and store into both a and b.


Let me quote from ANSI C++:


    5.17 Assignment operators [expr.ass]


1 There are several assignment operators, all of which group right-to-
    left. All require a modifiable lvalue as their left operand, and the
    type of an assignment expression is that of its left operand. The
    result of the assignment operation is the value stored in the left
    operand after the assignment has taken place; the result is an lvalue.


Do you know of any compilers that don't do it this way? Does the
wording of the C standard say something else?


>However, you might feel tempted to write it the short way:
>
> while ( *hw_reg = *the_string++ );
>
>expecting to get this more efficient assembly:
>
>loop:
> move.b (a0)+,(a1)
> bne loop
>
>Now this is where your SW/HW interaction blows up because this is
>what you get instead (on both compilers):
>
>..L21:
> move.b (%a0)+,(%a1)
> move.b (%a1),%d0
> jbne .L21
>Since hw_reg was declared volatile, the compiler should *not* assume that
>writing to it then reading from it will give the same result.


It is precisely because the value in the hardware register can be
anything, that we _must_ issue a read. The while refers to the
contents of the hardware register, not the contents of the string.


I think comp.lang.c is a better forum.


Anyway, in C++ land, it is reasonably clear what the semantics are.


>However, I had the apparently very dangerous assumption that gcc et
>al treated volatile with some sensible way (i.e. the number and order
>of read/write accesses is kept identical to what the C code would do
>without optimisation).


No, this is not a dangerous assumption. The asumption is that you
know the rules that gcc uses for volatile.


I'd be interested to hear about what other compilers do in this case, and
other cases such as:


main() {
volatile char *a, *b;
  ((*a)++) ;
  *b = ((*a)++) ;
  *b = (++(*a)) ;
  ++(*a) , ++ (*a);
}


Also if someone can state what c9x says about this, that would be
great. I think that the language standards should answer these types
of questions in a complete and unambiguous way. I am sorry that they
don't. Petition your languages standards to do this.
[As I recall, C9X doesn't change the definition of volatile in any
significant way. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.