On Wed, 27 Feb 2002, Matthew Dillon wrote:

> :/*
> : * Note: the "volatile" below does not REQUIRE that the argument be
> : * volatile, but rather ony says that it is OK to use a volatile * i
> : * there. Same for the const. I know a const volatile sounds strange
> : * but it only indicates that either is acceptable.
> : */
> :void    bcopy __P((volatile const void *from, volatile void *to, size_t
> :len));
>     I really don't like this.  I mean, it will work.... but I really don't
>     like this.  Volatile in C will effectively prevent optimization of
>     read and write accesses to the data the pointer is pointing at.  Of
>     course, this is bcopy(), which we implement in assembly, so again it will
>     work for bcopy().  But it sets a very bad coding precedent.

Volatile semantics also prevents optimizations in the assembly versions.
i586_bcopy already does extensive optimizations involving out of order
loads to prefetch cache lines.  i586_bzero does even more volatile-
unfriendly things for (dubious) alignment tricks.  Even overlapping
bcopies break volatile semantics (by copying backwards in some cases).

Similarly for memcpy.  bcopy and memcpy in the kernel should have the
same interface as in userland.

I think the correct fix is to always use bus space for hardware accesses,
and only use volatile elements or whole volatile structs for non-hardware
variables very rarely.  The bus space functions avoid optimizations
that are only valid for ordinary memory just by not using optimizations
that are not usefule for device memory.  Volatile variables don't work
so well for SMP systems since you often need to lock them anyway and the
lock makes them nonvolatile.

BTW, C's volatile semantics do not protect you from invalidly bcopy'ing
a non-volatile struct with volatile elements.  C just looks at the
qualifiers on the pointer to the struct and doesn't look inside the
struct.  Bcopy'ing such a struct gives undefined behaviour, so the
compiler is permitted to detect this error.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to