"Witold J. Wnuk" <w.wnuk@zodiac.mimuw.edu.pl> writes:
> And, I am more convinced now, bus_space_read should do read from the bus
> POV, bus_space_write should do write from the bus POV. C guarantes that
> functions are executed in order. We should mimic that behaviour.
> 
> This is what bus_space is for, right?

_no_.  bus_space does _not_ exist to provide C semantics for bus
access.

It exists to provide machine-independent access to bus space, with
whatever semantics are defined by it.  C semantics are pretty much
irrelevant, except inasmuch as C mandates that if you manipulate data
after reading it, you'll actually have read it.


> It is possible to save "mb" between writes:
> 
> something like:
> 
> extern int readsp;
> 
> #define write() do {                            \
>                 if (readsp) asm("mb");          \
>                 else asm("wmb");                \
>                 readsp = 0;                     \
>                 asm("write");                   \
>         } while (0)
> 
> 
> #define read() do {                             \
>                 asm("mb");                      \
>                 asm("read");                    \
>                 readsp = 1;                     \
>         } while (0)

except, in truly generic macros like this, you cannot reasonably use
'extern int' unless you know that the macros will be used without any
possibility of taking an interrupt or exception.  you really should be
using volatile int, and in that case, because if you do not you
_might_ lose.  (actually, even if you do, you might lose, since
there's no atomicity of access.)

the point is, if they're generic, then you don't know how they'll be
used, and so you can't take shortcuts.




cgd