From owner-freebsd-arch Mon Dec 31 4:55:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B829337B425 for ; Mon, 31 Dec 2001 04:55:34 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA27818; Mon, 31 Dec 2001 23:55:20 +1100 Date: Mon, 31 Dec 2001 23:55:10 +1100 (EST) From: Bruce Evans X-X-Sender: To: Alfred Perlstein Cc: Michal Mertl , Matthew Dillon , Subject: Re: 64 bit counters In-Reply-To: <20011229185917.J16101@elvis.mu.org> Message-ID: <20011231234620.O6481-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 29 Dec 2001, Alfred Perlstein wrote: > * Michal Mertl [011229 18:49] wrote: > > I doesn't seem too bad to me, but I do have a problem - I can't implement > > real atomic 64 bit operations on an i386. It shouldn't be named atomic_XXX > > if it isn't atomic. So that other people don't start to use it on <586 > > with some variable which changes fast. > > > > What about making the counters not 64 bit, but the size of biggest atomic > > type? Something like type u_maxatomic_t which would be 32 bit on <586 and > > 64 bit otherwise. There would still be problem in determining at compile > > time the size but we could choose the safe size if not somewhere defined > > otherwise. > > > > I can make changes to my local tree but how should I send them someone for > > review? Should I send them to arch? I tried to find the answer to this > > question in developers's handbook but didn't find it. > > *laff* the concept of atomic_t was initially proposed by me over > a year ago (i got the idea from linux) however it never seemed to > get done. atomic_t would be "int" if anything. I removed support for atomic operations on all types except "int" (and some pointers punned to int on i386's), and found that (on i386's) only 2 source files didn't compile. Both are easy to fix (one MD place used a char type for a set of flags that is followed by padding to a 32-bit boundary anyway, and one MI place uses long types which are equivalent to ints on i386's anyway). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message