lkml.org 
[lkml]   [2002]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 <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/

    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:2.633 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site