Date: Sun, 17 Dec 2000 15:47:35 -0800 (PST) From: John Polstra <TrimYourCc@polstra.com> To: smp@freebsd.org Cc: cp@bsdi.com Subject: Re: atomic increment? Message-ID: <200012172347.eBHNlZ764346@vashon.polstra.com> In-Reply-To: <200012171602.eBHG2wP13434@berserker.bsdi.com> References: <200012171602.eBHG2wP13434@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200012171602.eBHG2wP13434@berserker.bsdi.com>, Chuck Paterson <cp@bsdi.com> wrote: > > It was my understanding that declaring an asm volatile > would generate all the same symantics as calling a function at that > point. This is certainly the effect I have observed, and if you > want to us atomic operations for locking, such as spin locks, it > is the effect you better get. Am I wrong about this? This is why > I thought the data in registers would be almost all discarded. I wrote compilers for a living in a former life, so maybe I can shed some light on this. It's easiest to describe it in terms of what the compiler feels free to do when volatile is _not_ specified. In an asm statement, you specify inputs, outputs, and clobbers. The compiler makes sure it positions the asm statement such that the following constraints are satisfied when the asm statement executes: 1. All of the inputs have already been computed and are still valid. 2. None of the outputs have been needed yet by other computations. 3. The clobbers won't wipe out values that will be needed later. As long as it can satisfy these requirements, the compiler feels free to move your asm statement anywhere it wants to. That is normally perfectly OK; it's the same way the compiler treats the instructions it generates itself. But the tricky part is that the compiler doesn't know anything about your asm statement except what your input, output, and clobber specifications tell it. It doesn't know an "add" from a "cli" on its own. So if you don't make the specifications absolutely correct and complete, the compiler is likely to move your instruction to a place where its inputs won't be valid, or where it will clobber a register that it shouldn't. If an asm statment has no side-effects that aren't fully described in the output and clobber specifications, you shouldn't need volatile on it. But if it has side-effects that you can't express as outputs and clobbers, then you need volatile. For example, if an instruction disables or enables interrupts, you need volatile because you can't express that any other way. Without volatile, the compiler might even delete an asm entirely. It could do this if it knew that none of the output values were going to be used. For example, if an asm has one output value that goes to a local variable which is never used after that, and has no clobbers, the compiler will feel it can delete the asm entirely. And, if the input/output/clobber specifications are correct and complete, that will be perfectly OK. According to the gcc info pages (a good reference for this), adding volatile prevents an asm from "being deleted, moved significantly, or combined." I am reasonably confident this means the following: (1) All computations preceding the asm in the source will precede it in the final generated code, and (2) all computations following the asm in the source will follow it in the final generated code. I think we could get rid of a lot of volatiles if we made sure our input/output/clobber specifications were correct and complete. I know of at least one sense in which most of them are _not_ complete. On the x86, most instructions clobber the condition codes. The info pages say that you should indicate that in asm statements by putting "cc" in the clobber specification. We don't do that. I don't know whether it actually matters on the x86 port of gcc or not, but it would no doubt matter on some architectures. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012172347.eBHNlZ764346>