Date: Sat, 16 Dec 2000 23:59:28 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, Alfred Perlstein <bright@wintelcom.net>, smp@FreeBSD.ORG Subject: Re: atomic increment? Message-ID: <Pine.BSF.4.21.0012162337350.7092-100000@besplex.bde.org> In-Reply-To: <3A3AA04B.68EEB813@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Dec 2000, Julian Elischer wrote: > John Baldwin wrote: > > > > On 15-Dec-00 Alfred Perlstein wrote: > > > * John Baldwin <jhb@FreeBSD.ORG> [001215 10:51] wrote: > > >> > > >> On 15-Dec-00 Julian Elischer wrote: > > >> > CAn we have an atomic increment and decrement primative? No. They are just syntactic sugar for adding and subtracting 1. > > >> > presently we get: > > >> > > > >> > .L565: > > >> > movl $1,%eax > > >> >#APP > > >> > lock > > >> > addl %eax,4(%ebx) > > >> > > > >> > > > >> > the movl is totally useless and it would be > > >> > an absolutly trivial addition.. The movl is a gcc pessimization. gcc should generate: lock addl $1,4(%ebx) gcc did generate this for old versions of the atomic functions (it only started pessimizing this when we added some `volatile' qualifiers). The above (addl $1...) has exactly the same overheads as: lock incl 4(%ebx) except it is 1 byte longer so it may take longer to fetch (but instruction fetching hasn't been a significant bottleneck since the original 386, and I think the instruction fetcher will have even more time to keep up than usual because the lock instruction slows things down). > > I didn't come up with it. :) atomic_add_int(&my_int_var, 1) doesn't appear too > > weird to me. Of course, the movl being complained about is actually rather > > rediculous. It's in the instruction cache, so the '1' is a cache hit, and this > > instruction is probably all of 1 clock. Compared to the overhead of the bus Or 0 clocks, if it is done in parallel with the previous instruction. > the mov uses up a register which in one example I was using here, forced > a much needed number to be written to memory and later restored. True, but this is gcc's fault. Bruce 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?Pine.BSF.4.21.0012162337350.7092-100000>