Skip site navigation (1)Skip section navigation (2)
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>