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>