volatile and "needed side effects"

[dingoatemydonut]

The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:

extern volatile int *p;

int main(void)
{
*p;
return 0;
}

[Eric Sosman]

di************* @aol.com wrote On 10/10/05 15:26,:

The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:

extern volatile int *p;

int main(void)
{
*p;
return 0;
}

Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.

--
Er*********@sun .com

[Keith Thompson]

Eric Sosman <er*********@su n.com> writes:

di************* @aol.com wrote On 10/10/05 15:26,:

The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:

extern volatile int *p;

int main(void)
{
*p;
return 0;
}

Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.

Right -- unless the compiler knows somehow that accessing *p doesn't
actually have a "needed side effect". But since the user went out of
his way to declare it volatile, it's unlikely that a compiler would go
to the effort to prove this, especially since it might be wrong.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Eric Sosman]

Keith Thompson wrote On 10/10/05 16:31,:

Eric Sosman <er*********@su n.com> writes:

di*********** **@aol.com wrote On 10/10/05 15:26,:

The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:

extern volatile int *p;

int main(void)
{
*p;
return 0;
}

Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.

Right -- unless the compiler knows somehow that accessing *p doesn't
actually have a "needed side effect". But since the user went out of
his way to declare it volatile, it's unlikely that a compiler would go
to the effort to prove this, especially since it might be wrong.

Right (back at'cha). It is, however, rather difficult to
reason about volatile in a portable way. The Standard requires
that all the accesses the abstract machine would make must
actually be made, but since the implementation gets to define
what "access" means ...

--
Er*********@sun .com

[Keyser Soze]

"Eric Sosman" <er*********@su n.com> wrote in message
news:di******** **@news1brm.Cen tral.Sun.COM...

Keith Thompson wrote On 10/10/05 16:31,:

Eric Sosman <er*********@su n.com> writes:

di********** ***@aol.com wrote On 10/10/05 15:26,:

The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:

extern volatile int *p;

int main(void)
{
*p;
return 0;
}

Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.

Right -- unless the compiler knows somehow that accessing *p doesn't
actually have a "needed side effect". But since the user went out of
his way to declare it volatile, it's unlikely that a compiler would go
to the effort to prove this, especially since it might be wrong.

Right (back at'cha). It is, however, rather difficult to
reason about volatile in a portable way. The Standard requires
that all the accesses the abstract machine would make must
actually be made, but since the implementation gets to define
what "access" means ...

We do a lot of embedded C code so we test compiliers on how they handle
volatile data types. Some of the test code we use is so abreviated as to
have no real functionality other than to test the code generator.

One compiler we tested claims to conform with ISO C but has a somewhat
nonconformist way of working with volatile data types.

Specifically:

int volatile a;

void test1(void)
{
a = a + 0;
}

void test2(void)
{
a += 0;
}

The code produced by function test1 was correct.

The variable 'a' was read then written.

The code produced by function test2 was incorrect.

The variable 'a' was read but not written.

When we suggested that the code for test2 did not conform we were told the
expression has only one sequence point and that the generated code was
correct.

We did not use that compiler.

Not because there was not a way to work around this particular issue but
because there was now way to know how many more of these kinds of things may
be lurking within their code generator.

[Mark F. Haigh]

Keyser Soze wrote:
<snip>

We do a lot of embedded C code so we test compiliers on how they handle
volatile data types. Some of the test code we use is so abreviated as to
have no real functionality other than to test the code generator.

One compiler we tested claims to conform with ISO C but has a somewhat
nonconformist way of working with volatile data types.

Specifically:

int volatile a;

void test1(void)
{
a = a + 0;
}

void test2(void)
{
a += 0;
}

The code produced by function test1 was correct.

The variable 'a' was read then written.

The code produced by function test2 was incorrect.

The variable 'a' was read but not written.

When we suggested that the code for test2 did not conform we were told the
expression has only one sequence point and that the generated code was
correct.

Using compound assignment operators when dealing with
volatile-qualified objects that are "sensitive" to the difference
(usually hardware registers) is a classic no-no. Here's my best
explanation:

C99: 5.1.2.3 Program execution

[#6] The least requirements on a conforming implementation are:

-- At sequence points, volatile objects are stable in the
sense that previous accesses are complete and
subsequent accesses have not yet occurred.
GCC 4.02 Manual:
4 C Implementation-defined behavior
4.10 Qualifiers - When is a Volatile Object Accessed?

[...]
The minimum either standard specifies is that at a
sequence point all previous accesses to volatile objects
have stabilized and no subsequent accesses have occurred.
Thus an implementation is free to reorder and combine
volatile accesses which occur between sequence points,
but cannot do so for accesses across a sequence point.
6.7.3 Type qualifiers

[#6] An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other
unknown side effects. Therefore any expression referring to
such an object shall be evaluated strictly according to the
rules of the abstract machine [...]
6.5.16.2 Compound assignment

[#3] A compound assignment of the form E1 op= E2 differs
from the simple assignment expression E1 = E1 op (E2) only
in that the lvalue E1 is evaluated only once.
"E1" is evaluated "only once", and implementations are (at least
according to the GCC group's interpretation) "free to reorder and
combine volatile accesses which occur between sequence points". I
believe the compiler's behavior in this case is conforming.

At least that's my interpretation. Dissent or confirmation is welcome.
Personally speaking, I have never used compound assignment to
volatile-qualified types in any device drivers I've ever written.

<snip>

Mark F. Haigh
mf*****@sbcglob al.net

[Keyser Soze]

"Mark F. Haigh" <mf*****@sbcglo bal.net> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Keyser Soze wrote:
<snip>

We do a lot of embedded C code so we test compiliers on how they handle
volatile data types. Some of the test code we use is so abreviated as to
have no real functionality other than to test the code generator.

One compiler we tested claims to conform with ISO C but has a somewhat
nonconformist way of working with volatile data types.

Specifically:

int volatile a;

void test1(void)
{
a = a + 0;
}

void test2(void)
{
a += 0;
}

The code produced by function test1 was correct.

The variable 'a' was read then written.

The code produced by function test2 was incorrect.

The variable 'a' was read but not written.

When we suggested that the code for test2 did not conform we were told
the
expression has only one sequence point and that the generated code was
correct.

Using compound assignment operators when dealing with
volatile-qualified objects that are "sensitive" to the difference
(usually hardware registers) is a classic no-no. Here's my best
explanation:

C99: 5.1.2.3 Program execution

[#6] The least requirements on a conforming implementation are:

-- At sequence points, volatile objects are stable in the
sense that previous accesses are complete and
subsequent accesses have not yet occurred.
GCC 4.02 Manual:
4 C Implementation-defined behavior
4.10 Qualifiers - When is a Volatile Object Accessed?

[...]
The minimum either standard specifies is that at a
sequence point all previous accesses to volatile objects
have stabilized and no subsequent accesses have occurred.
Thus an implementation is free to reorder and combine
volatile accesses which occur between sequence points,
but cannot do so for accesses across a sequence point.
6.7.3 Type qualifiers

[#6] An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other
unknown side effects. Therefore any expression referring to
such an object shall be evaluated strictly according to the
rules of the abstract machine [...]
6.5.16.2 Compound assignment

[#3] A compound assignment of the form E1 op= E2 differs
from the simple assignment expression E1 = E1 op (E2) only
in that the lvalue E1 is evaluated only once.
"E1" is evaluated "only once", and implementations are (at least
according to the GCC group's interpretation) "free to reorder and
combine volatile accesses which occur between sequence points". I
believe the compiler's behavior in this case is conforming.

At least that's my interpretation. Dissent or confirmation is welcome.
Personally speaking, I have never used compound assignment to
volatile-qualified types in any device drivers I've ever written.

The standard and implementation guides are a little vague and hand wavy on
just exactly what is meant by "evaluated only once" when processing a
compound assignment involving a volatile data type.

--------------------

ansi_iso_iec_98 99, Section 6.7.3, footnote:

114) A volatile declaration may be used to describe an object corresponding
to a memory-mapped input/output port or an object accessed by an
asynchronously interrupting function. Actions on objects so declared shall
not be "optimized out" by an implementation or reordered except as permitted
by the rules for evaluating expressions.

--------------------

The syntax of the statement would imply that one read and one write would
always be performed on the volatile lvalue of a compound assignment.

This would seem to require that compound assignments to volatile lvaues have
two sequence points. One at the "read" evaluation of E1 and one at the
"write" operation of E2.

The bottom line here seems to be if you need to use volatile data types to
access hardware you had better take a good look at an example of the
generated code for side affects.

[Mark F. Haigh]

Keyser Soze wrote:

"Mark F. Haigh" <mf*****@sbcglo bal.net> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Keyser Soze wrote:
<snip>

"E1" is evaluated "only once", and implementations are (at least
according to the GCC group's interpretation) "free to reorder and
combine volatile accesses which occur between sequence points". I
believe the compiler's behavior in this case is conforming.

At least that's my interpretation. Dissent or confirmation is welcome.
Personally speaking, I have never used compound assignment to
volatile-qualified types in any device drivers I've ever written.

The standard and implementation guides are a little vague and hand wavy on
just exactly what is meant by "evaluated only once" when processing a
compound assignment involving a volatile data type.

--------------------

ansi_iso_iec_98 99, Section 6.7.3, footnote:

114) A volatile declaration may be used to describe an object corresponding
to a memory-mapped input/output port or an object accessed by an
asynchronously interrupting function. Actions on objects so declared shall
not be "optimized out" by an implementation or reordered except as permitted
by the rules for evaluating expressions.

--------------------

The syntax of the statement would imply that one read and one write would
always be performed on the volatile lvalue of a compound assignment.

This would seem to require that compound assignments to volatile lvaues have
two sequence points. One at the "read" evaluation of E1 and one at the
"write" operation of E2.

Footnotes are not normative: See the C99 Forward:

[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.

The bottom line here seems to be if you need to use volatile data types to
access hardware you had better take a good look at an example of the
generated code for side affects.

Agreed, but using compound assignments to write hardware registers is
never a good idea.
Mark F. Haigh
mf*****@sbcglob al.net

[Mark F. Haigh]

Eric Sosman wrote:

Mark F. Haigh wrote On 10/11/05 16:01,:

Footnotes are not normative: See the C99 Forward:

[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.

But the Foreword (not "Forward") is also non-normative!
Why should we believe anything it says? In particular, why
should we believe what it says about footnotes?

(And the reference to ISO/IED directives is within the
non-normative Foreword, so it can't be taken seriously ;-)

Nice! How about:

The ISO/IEC Directives, Part 3, section 6.5, classify footnotes to text
as "other informative elements", and as such are not considered to be
normative.
Mark F. Haigh
mf*****@sbcglob al.net

[Ben Pfaff]

Eric Sosman <er*********@su n.com> writes:

Mark F. Haigh wrote On 10/11/05 16:01,:

Footnotes are not normative: See the C99 Forward:

[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.

But the Foreword (not "Forward") is also non-normative!
Why should we believe anything it says? In particular, why
should we believe what it says about footnotes?

How do you know that the Foreword is non-normative? You seem to
believe that it is so only on the basis of what the Foreword
says, but that's not a valid source because it is non-normative.
--
Are we recursing yet?