[lkml]   [2002]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: readl/writel and memory barriers
On Wed, 20 Feb 2002, Keith Owens wrote:

| On Tue, 19 Feb 2002 10:35:06 -0800,
| Jesse Barnes <> 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.

| [#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.

| [#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
| -


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean