Xref: utzoo comp.arch:21637 comp.lang.c:37537 Newsgroups: comp.arch,comp.lang.c Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Subject: Re: New SPARC definition, and volatile Message-ID: Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC References: <1991Mar21.185847.27784@elroy.jpl.nasa.gov> <40492@cup.portal.com> Date: Mon, 25 Mar 91 15:16:29 GMT C-language followups: please redirect to comp.lang.c Architecture followups: please redirect to comp.arch In article <40492@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: > The version 8 specification adds integer multiply and divide instructions. > In addition, a "Store Barrier" instruction was added that requires all stores > initiated before it to be completed before operation can continue. This is > designed to support future multiprocessor machines that allow memory > operations to occur out-of-order. One thing that occurred to me, reading this, is what impact this sort of instruction has on the use of "volatile" in C. If "volatile" implies the use of a "store barrier" instruction on writes, this would impact the performance of software that's using volatile to (for example) synchronise lightweight processes on a single CPU, but to not use it would break s/w that's using spinlocks for multiprocessor synchronisation. What's the answer? "#pragma really_volatile"? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"