Messages in this thread | | | Date | Wed, 20 Feb 2002 16:29:26 -0800 (PST) | From | "Randy.Dunlap" <> | Subject | Re: readl/writel and memory barriers |
| |
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/
| |