On Wed, 20 Feb 2002, Keith Owens wrote:
| On Tue, 19 Feb 2002 10:35:06 -0800,
| Jesse Barnes <jbarnes@sgi.com> wrote:
| >Making a variable volatile doesn't guarantee that the compiler won't
| >reorder references to it, AFAIK. And on some platforms, even uncached
| >I/O references aren't necessarily ordered.
|
| Ignoring the issue of hardware that reorders I/O, volatile accesses
| must not be reordered by the compiler. From a C9X draft (1999, anybody
| have the current C standard online?) :-
PDF file, for about US$18 - US$20, downloaded from ISO.
| 5.1.2.3 [#2]
|
| Accessing a volatile object, modifying an object, modifying a file,
| or calling a function that does any of those operations are all side
| effects which are changes in the state of the execution environment.
| Evaluation of an expression may produce side effects. At certain
| specified points in the execution sequence called sequence points,
| all side effects of previous evaluations shall be complete and no
| side effects of subsequent evaluations shall have taken place.
No changes here.
| 5.1.2.3 [#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.
Same text, although it's #5 now.
| The compiler may not reorder volatile accesses across sequence points.
|
| volatile int *a, *b;
| int c;
|
| c = *a + *b; // no sequence point, access order to a, b is undefined
|
| c = *a; // compiler must not convert to the above format, it
| c += *b; // must access a then b
|
|
| -
--- ~Randy- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:28 EST