Date: Tue, 9 Oct 2001 21:49:24 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.org> Cc: <cvs-all@FreeBSD.org>, <cvs-committers@FreeBSD.org> Subject: Re: cvs commit: src/sys/i386/include atomic.h Message-ID: <20011009204225.O24682-100000@delplex.bde.org> In-Reply-To: <XFMail.011008221355.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Oct 2001, John Baldwin wrote: > On 09-Oct-01 Bruce Evans wrote: > > On Mon, 8 Oct 2001, John Baldwin wrote: > >> [atomic ops...] > > > > I don't want the current bad interface exported to userland where it is > > harder to fix. The interface should by type-generic. E.g., > > atomic_add(lvalue, rvalue) instead of: > > So use the gcc-specific typeof()? :) The code calling atomic_* knows what type Nah, just use sizeof() ... > it is using. Why make the compiler guess what that type is so it can call the > proper primitive? Just like at the x86 PCPU macros to see how gross this can ... as in the x86 PCPU macros :-), except for not using so many casts. I can't see much use of typeof() here except to to generate better error messages. It could be used if %L worked: #define atomic_add(var, val) \ __asm __volatile("lock; add%L0 %1,%0" \ : "=m" (var) \ : "ir" ((typeof(var))val)); but %L apparently only works in .md files. Maybe this will be fixed to support type-generic macros in C99. > get. Now repeat that for each atomic operation with variations for the acquire > and release memory barriers. Ugh. It's better to have the complications in the implementation than the callers. I prefer the implementation complications for the x86 PCPU() to the current ones for the x86 atomic operations anyway. The macros aren't layered as deep. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011009204225.O24682-100000>