This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Assignment operator - summary
- To: gcc at gcc dot gnu dot org, zoltan at bendor dot com dot au
- Subject: Re: Assignment operator - summary
- From: Mike Stump <mrs at wrs dot com>
- Date: Tue, 12 Oct 1999 20:15:26 -0700 (PDT)
> 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.