Velocity Reviews > x=r=y; // With r volatile. Is r read?

# x=r=y; // With r volatile. Is r read?

Francois Grieu
Guest
Posts: n/a

 03-07-2011
Hi, the subject sums it all.

extern volatile unsigned r;
unsigned x,y;

void test(void)
{
x=r=y;
}

What happens:
- y is read, written in r and in x.
- y is read, written in r; then r is read, written in x.
- any of the above.
- other..

TIA,
Francois Grieu

Mark Bluemel
Guest
Posts: n/a

 03-07-2011
On 03/07/2011 04:05 PM, Francois Grieu wrote:
> Hi, the subject sums it all.
>
> extern volatile unsigned r;
> unsigned x,y;
>
> void test(void)
> {
> x=r=y;
> }
>
> What happens:
> - y is read, written in r and in x.
> - y is read, written in r; then r is read, written in x.
> - any of the above.
> - other..

to "x=(r=y);".

That is to say that the value of the expression "r=y" is assigned to x -
so there is no need for r to be read.

Francois Grieu
Guest
Posts: n/a

 03-07-2011
On 07/03/2011 17:33, Mark Bluemel wrote:
> On 03/07/2011 04:05 PM, Francois Grieu
>> Hi, the subject sums it all.
>>
>> extern volatile unsigned r;
>> unsigned x,y;
>>
>> void test(void)
>> {
>> x=r=y;
>> }
>>
>> What happens:
>> - y is read, written in r and in x.
>> - y is read, written in r; then r is read, written in x.
>> - any of the above.
>> - other..

>
> My reading of this is that your statement is exactly equivalent
> to "x=(r=y);".

Yes.

> That is to say that the value of the expression "r=y" is assigned to x

Yes.

> so there is no need for r to be read.

I'm unsure of that, and of if "no need" translates to "no read".
My problem boils down to: is the value of (r=y)
- the value read from y (that gets written into r).
- the value read from r (after?) writing the value of y into r.
- any of the above.
- other..

Francois Grieu

Mark Bluemel
Guest
Posts: n/a

 03-07-2011
On 03/07/2011 04:41 PM, Francois Grieu wrote:
> On 07/03/2011 17:33, Mark Bluemel wrote:
>> On 03/07/2011 04:05 PM, Francois Grieu
>>> Hi, the subject sums it all.
>>>
>>> extern volatile unsigned r;
>>> unsigned x,y;
>>>
>>> void test(void)
>>> {
>>> x=r=y;
>>> }
>>>
>>> What happens:
>>> - y is read, written in r and in x.
>>> - y is read, written in r; then r is read, written in x.
>>> - any of the above.
>>> - other..

>>
>> My reading of this is that your statement is exactly equivalent
>> to "x=(r=y);".

>
> Yes.
>
>> That is to say that the value of the expression "r=y" is assigned to x

>
> Yes.
>
>> so there is no need for r to be read.

>
> I'm unsure of that, and of if "no need" translates to "no read".
> My problem boils down to: is the value of (r=y)
> - the value read from y (that gets written into r).
> - the value read from r (after?) writing the value of y into r.
> - any of the above.
> - other..

http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf
6.5.16 paragraph 3
.... An assignment expression has the value of the left operand after the
assignment ....

I see no mention of other operations after the assignment.

lawrence.jones@siemens.com
Guest
Posts: n/a

 03-07-2011
Francois Grieu <(E-Mail Removed)> wrote:
>
> My problem boils down to: is the value of (r=y)
> - the value read from y (that gets written into r).
> - the value read from r (after?) writing the value of y into r.
> - any of the above.

Any of the above. "What constitutes an access to an object that has
volatile-qualified type is implementation-defined." (6.7.3p7) The
implementation is permitted to read the value from r, but it is not
required to.
--
Larry Jones

I think grown-ups just ACT like they know what they're doing. -- Calvin

Jens
Guest
Posts: n/a

 03-07-2011

On 7 Mrz., 20:33, (E-Mail Removed) wrote:
> Any of the above. *"What constitutes an access to an object that has
> volatile-qualified type is implementation-defined." (6.7.3p7) *The
> implementation is permitted to read the value from r, but it is not
> required to.

Exactly. The draft of C1X even has a footnote (in assignment
operators) to make the situation in question explicit:

C1X> The implementation is permitted to read the object to determine
the value but is not
C1X> required to, even when the object has volatile-qualified type.

Jens

Francois Grieu
Guest
Posts: n/a

 03-08-2011
On 07/03/2011 22:42, Jens wote on my question <quote>
>>>> My problem boils down to: is the value of (r=y)
>>>> - the value read from y (that gets written into r).
>>>> - the value read from r (after?) writing the value of y into r.
>>>> - any of the above.
>>>> - other.. </quote>

>
> On 7 Mrz., 20:33, (E-Mail Removed) wrote:
>> Any of the above. "What constitutes an access to an object that has
>> volatile-qualified type is implementation-defined." (6.7.3p7) The
>> implementation is permitted to read the value from r, but it is not
>> required to.

>
> Exactly. The draft of C1X even has a footnote (in assignment
> operators) to make the situation in question explicit:
>
> C1X> The implementation is permitted to read the object to determine
> the value but is not
> C1X> required to, even when the object has volatile-qualified type.

Yes. Quoting <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf>
more in depth:

" 6.5.16 Assignment operators (..)
p3) An assignment operator stores a value in the object designated by
the left operand. An assignment expression has the value of the
left operand after the assignment, (note 111) but is not an lvalue.
(..)

(111) The implementation is permitted to read the object to determine
the value but is not required to, even when the object has
volatile-qualified type. "

That settles (r=y) can have either
- the value read from y that also gets written into r
- the value read from r AFTER writing the value of y into r

Thanks.

Francois Grieu

Noob
Guest
Posts: n/a

 03-08-2011
Francois Grieu wrote:

> extern volatile unsigned r;
> unsigned x,y;
>
> void test(void)
> {
> x=r=y;
> }
>
> What happens:
> - y is read, written in r and in x.
> - y is read, written in r; then r is read, written in x.
> - any of the above.
> - other..

On a related note, I'd like to point to an (IMHO) interesting paper.

Volatiles Are Miscompiled, and What to Do about It
http://www.cs.utah.edu/~regehr/paper...8-preprint.pdf

Regards.

Guest
Posts: n/a

 03-08-2011
On Mar 8, 7:18*am, Kenneth Brody <(E-Mail Removed)> wrote:
> On 3/7/2011 12:00 PM, Mark Bluemel wrote:
>
>
>
> > On 03/07/2011 04:41 PM, Francois Grieu wrote:
> >> On 07/03/2011 17:33, Mark Bluemel wrote:
> >>> On 03/07/2011 04:05 PM, Francois Grieu
> >>>> Hi, the subject sums it all.

>
> >>>> extern volatile unsigned r;
> >>>> unsigned x,y;

>
> >>>> void test(void)
> >>>> {
> >>>> x=r=y;
> >>>> }

> [...]
> >>> so there is no need for r to be read.

>
> >> I'm unsure of that, and of if "no need" translates to "no read".
> >> My problem boils down to: is the value of (r=y)
> >> - the value read from y (that gets written into r).
> >> - the value read from r (after?) writing the value of y into r.
> >> - any of the above.
> >> - other..

>
> >http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf
> > 6.5.16 paragraph 3
> > .... An assignment expression has the value of the left operand after the
> > assignment ....

>
> > I see no mention of other operations after the assignment.

>
> Consider the fact that, with a volatile, the "value of the left operand
> after the assignment" might not necessarily be the value that was just
> assigned to it.
>

Would this be because the assignment produces a side effect?

Guest
Posts: n/a

 03-08-2011
On Mar 7, 8:33*am, Mark Bluemel <(E-Mail Removed)> wrote:
> On 03/07/2011 04:05 PM, Francois Grieu wrote:
>
> > Hi, the subject sums it all.

>
> > extern volatile unsigned r;
> > unsigned x,y;

>
> > void test(void)
> > * {
> > * x=r=y;
> > * }

>
> > What happens:
> > - y is read, written in r and in x.
> > - y is read, written in r; then r is read, written in x.
> > - any of the above.
> > - other..

>
> My reading of this is that your statement is exactly equivalent
> to "x=(r=y);".
>
> That is to say that the value of the expression "r=y" is assigned to x -
> so there is no need for r to be read.

I don't know about C, but some other programming languages would refer
to this as "right associative".