Date: Thu, 28 Feb 2002 20:07:44 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Julian Elischer <julian@elischer.org>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: controversial fix or some errors breaking LINT Message-ID: <20020228194250.A51954-100000@gamplex.bde.org> In-Reply-To: <200202272228.g1RMSoX31270@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020228194250.A51954-100000>