This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Assignment operator - summary


> From: Zoltan Kocsi <zoltan@bendor.com.au>
> Date: Wed, 13 Oct 1999 11:56:56 +1000 (EST)

> - The assignment operator's value is the value that can be read back
>   from the LHS after the assignment.

Right, for C++. Wrong for C and volatile.

>   In conventional memory it happens to be identical to the value
>   written to the LHS.

Right.

>   It is just as right, because some people who learnt C from the K&R
>   books live in the false belief that the value of an assignment is
>   actually the value that's written to the LHS. (Let's call them RHS
>   believers.)

This isn't a false belief for C and volatile.  For C and nonvolatile,
the optimizer is allowed to do this.

> - The compiler has the ANSI C Standard guaranteed right to re-read the 
>   LHS

No, ANSI C mandates it won't re-read, if volatile.

>   or to use the value that it wrote to the LHS, even if the LHS is 
>   volatile. It thus demolishes the difference between the LHS believers 
>   and the RHS believers because neither of them can predict what the 
>   compiler will do.

Wrong, we all can predict what the compiler will do, if only someone
explains it, and we grasp the rules.

> - When the compiler decides to re-fetch the LHS and the location of
>   the LHS itself is volatile, it is up to the compiler to decide
>   whether it re-calculates the location to fetch from or uses the 
>   location it did the write to.

Wrong. There must be no re-calculation of the address.

> - Although the standard does not guarantee it, thou shall have faith 
>   in thy Compiler Writers that in the case of var = expr; they will 
>   only generate a single write to var and in the case of temp = var; 
>   they will generate a single read from var, would var be volatile.
>   Let us all rejoyce !

It is guaranteed for C++, right, but a single write might surprise you
if you don't know what it means.  In C, the standard has a bug of
incompleteness in it that they will fix at some point.  We can treat
the C standard as if they had said it.  :-P

> - As a consequence, those who are qualified to use volatile must write
>   all their code with constantly fetching all their volatile objects 
>   to temporaries in conventional memory, processing the memory then 
>   writing the results back to the volatile locations. No construct other 
>   than <var> = <expr>; or <temp> = <var>; should be used on volatile
>   <var> objects.

Wrong.

> - No C lib function can be used with any operands that are not in
>   conventional memory. If you need the functionality in an environment 
>   that can support non-conventional memory, you should re-implement
>   the standard C library either in assembly, or, based on the faith
>   above, in C but using only simple assignments to access the volatile
>   objects.

That's right.  You can't predict the exact nature of reads and write
to volatile objects when you pass them to qsort.  Now you're getting
the hang of it.  If you application requires a particular set of reads
and writes to this volatile data, thou slat not use qsort.  If you
don't care, then qsort is fine.  Only you can know if you care.

> Do I see it right ?

Nope, not completely.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]