1998-08-24 08:39:39 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 1998 Doug Rabson
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*
|
1999-08-28 01:08:13 +00:00
|
|
|
* $FreeBSD$
|
1998-08-24 08:39:39 +00:00
|
|
|
*/
|
|
|
|
#ifndef _MACHINE_ATOMIC_H_
|
2005-07-09 12:38:53 +00:00
|
|
|
#define _MACHINE_ATOMIC_H_
|
1998-08-24 08:39:39 +00:00
|
|
|
|
2005-03-02 21:33:29 +00:00
|
|
|
#ifndef _SYS_CDEFS_H_
|
|
|
|
#error this file needs sys/cdefs.h as a prerequisite
|
|
|
|
#endif
|
|
|
|
|
2009-10-06 23:48:28 +00:00
|
|
|
#define mb() __asm __volatile("mfence;" : : : "memory")
|
|
|
|
#define wmb() __asm __volatile("sfence;" : : : "memory")
|
|
|
|
#define rmb() __asm __volatile("lfence;" : : : "memory")
|
2008-11-22 05:55:56 +00:00
|
|
|
|
1998-08-24 08:39:39 +00:00
|
|
|
/*
|
2006-12-29 15:29:49 +00:00
|
|
|
* Various simple operations on memory, each of which is atomic in the
|
|
|
|
* presence of interrupts and multiple processors.
|
1998-08-24 08:39:39 +00:00
|
|
|
*
|
2006-12-29 14:28:23 +00:00
|
|
|
* atomic_set_char(P, V) (*(u_char *)(P) |= (V))
|
|
|
|
* atomic_clear_char(P, V) (*(u_char *)(P) &= ~(V))
|
|
|
|
* atomic_add_char(P, V) (*(u_char *)(P) += (V))
|
|
|
|
* atomic_subtract_char(P, V) (*(u_char *)(P) -= (V))
|
1999-07-13 06:35:25 +00:00
|
|
|
*
|
2006-12-29 14:28:23 +00:00
|
|
|
* atomic_set_short(P, V) (*(u_short *)(P) |= (V))
|
|
|
|
* atomic_clear_short(P, V) (*(u_short *)(P) &= ~(V))
|
|
|
|
* atomic_add_short(P, V) (*(u_short *)(P) += (V))
|
|
|
|
* atomic_subtract_short(P, V) (*(u_short *)(P) -= (V))
|
1999-07-13 06:35:25 +00:00
|
|
|
*
|
2006-12-29 14:28:23 +00:00
|
|
|
* atomic_set_int(P, V) (*(u_int *)(P) |= (V))
|
|
|
|
* atomic_clear_int(P, V) (*(u_int *)(P) &= ~(V))
|
|
|
|
* atomic_add_int(P, V) (*(u_int *)(P) += (V))
|
|
|
|
* atomic_subtract_int(P, V) (*(u_int *)(P) -= (V))
|
2006-12-29 15:29:49 +00:00
|
|
|
* atomic_readandclear_int(P) (return (*(u_int *)(P)); *(u_int *)(P) = 0;)
|
1999-07-13 06:35:25 +00:00
|
|
|
*
|
2006-12-29 14:28:23 +00:00
|
|
|
* atomic_set_long(P, V) (*(u_long *)(P) |= (V))
|
|
|
|
* atomic_clear_long(P, V) (*(u_long *)(P) &= ~(V))
|
|
|
|
* atomic_add_long(P, V) (*(u_long *)(P) += (V))
|
|
|
|
* atomic_subtract_long(P, V) (*(u_long *)(P) -= (V))
|
2006-12-29 15:29:49 +00:00
|
|
|
* atomic_readandclear_long(P) (return (*(u_long *)(P)); *(u_long *)(P) = 0;)
|
1998-08-24 08:39:39 +00:00
|
|
|
*/
|
|
|
|
|
1999-07-13 06:35:25 +00:00
|
|
|
/*
|
1999-08-18 04:08:31 +00:00
|
|
|
* The above functions are expanded inline in the statically-linked
|
|
|
|
* kernel. Lock prefixes are generated if an SMP kernel is being
|
|
|
|
* built.
|
|
|
|
*
|
|
|
|
* Kernel modules call real functions which are built into the kernel.
|
|
|
|
* This allows kernel modules to be portable between UP and SMP systems.
|
1999-07-13 06:35:25 +00:00
|
|
|
*/
|
2006-12-28 08:15:14 +00:00
|
|
|
#if defined(KLD_MODULE) || !defined(__GNUCLIKE_ASM)
|
2005-07-09 12:38:53 +00:00
|
|
|
#define ATOMIC_ASM(NAME, TYPE, OP, CONS, V) \
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
void atomic_##NAME##_##TYPE(volatile u_##TYPE *p, u_##TYPE v); \
|
|
|
|
void atomic_##NAME##_barr_##TYPE(volatile u_##TYPE *p, u_##TYPE v)
|
1999-08-18 04:08:31 +00:00
|
|
|
|
2010-05-20 06:18:03 +00:00
|
|
|
int atomic_cmpset_int(volatile u_int *dst, u_int expect, u_int src);
|
|
|
|
int atomic_cmpset_long(volatile u_long *dst, u_long expect, u_long src);
|
2006-12-29 14:28:23 +00:00
|
|
|
u_int atomic_fetchadd_int(volatile u_int *p, u_int v);
|
2008-03-16 21:20:50 +00:00
|
|
|
u_long atomic_fetchadd_long(volatile u_long *p, u_long v);
|
2000-09-06 11:21:14 +00:00
|
|
|
|
2001-01-16 00:18:36 +00:00
|
|
|
#define ATOMIC_STORE_LOAD(TYPE, LOP, SOP) \
|
|
|
|
u_##TYPE atomic_load_acq_##TYPE(volatile u_##TYPE *p); \
|
2002-07-17 16:19:37 +00:00
|
|
|
void atomic_store_rel_##TYPE(volatile u_##TYPE *p, u_##TYPE v)
|
2001-01-16 00:18:36 +00:00
|
|
|
|
2006-12-28 08:15:14 +00:00
|
|
|
#else /* !KLD_MODULE && __GNUCLIKE_ASM */
|
2002-07-18 15:56:46 +00:00
|
|
|
|
2001-10-08 20:58:24 +00:00
|
|
|
/*
|
2006-12-29 15:29:49 +00:00
|
|
|
* For userland, always use lock prefixes so that the binaries will run
|
|
|
|
* on both SMP and !SMP systems.
|
2001-10-08 20:58:24 +00:00
|
|
|
*/
|
2003-11-17 08:58:16 +00:00
|
|
|
#if defined(SMP) || !defined(_KERNEL)
|
2006-12-29 13:36:26 +00:00
|
|
|
#define MPLOCKED "lock ; "
|
2002-02-11 03:41:59 +00:00
|
|
|
#else
|
2005-07-09 12:38:53 +00:00
|
|
|
#define MPLOCKED
|
2002-02-11 03:41:59 +00:00
|
|
|
#endif
|
1999-07-13 03:32:17 +00:00
|
|
|
|
1999-07-13 06:35:25 +00:00
|
|
|
/*
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
* The assembly is volatilized to avoid code chunk removal by the compiler.
|
|
|
|
* GCC aggressively reorders operations and memory clobbering is necessary
|
|
|
|
* in order to avoid that for memory barriers.
|
1999-07-13 06:35:25 +00:00
|
|
|
*/
|
2005-07-09 12:38:53 +00:00
|
|
|
#define ATOMIC_ASM(NAME, TYPE, OP, CONS, V) \
|
1999-07-13 06:35:25 +00:00
|
|
|
static __inline void \
|
1999-07-23 23:45:50 +00:00
|
|
|
atomic_##NAME##_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
|
1999-07-13 06:35:25 +00:00
|
|
|
{ \
|
2006-12-29 13:36:26 +00:00
|
|
|
__asm __volatile(MPLOCKED OP \
|
2006-12-29 14:28:23 +00:00
|
|
|
: "=m" (*p) \
|
2010-12-18 16:41:11 +00:00
|
|
|
: CONS (V), "m" (*p) \
|
|
|
|
: "cc"); \
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
} \
|
|
|
|
\
|
|
|
|
static __inline void \
|
|
|
|
atomic_##NAME##_barr_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
|
|
|
|
{ \
|
|
|
|
__asm __volatile(MPLOCKED OP \
|
|
|
|
: "=m" (*p) \
|
|
|
|
: CONS (V), "m" (*p) \
|
2010-12-18 16:41:11 +00:00
|
|
|
: "memory", "cc"); \
|
2003-11-21 03:02:00 +00:00
|
|
|
} \
|
|
|
|
struct __hack
|
2002-07-18 15:56:46 +00:00
|
|
|
|
2000-09-06 11:21:14 +00:00
|
|
|
/*
|
|
|
|
* Atomic compare and set, used by the mutex functions
|
|
|
|
*
|
2010-05-20 06:18:03 +00:00
|
|
|
* if (*dst == expect) *dst = src (all 32 bit words)
|
2000-09-06 11:21:14 +00:00
|
|
|
*
|
|
|
|
* Returns 0 on failure, non-zero on success
|
|
|
|
*/
|
|
|
|
|
2009-10-09 15:51:40 +00:00
|
|
|
static __inline int
|
2010-05-20 06:18:03 +00:00
|
|
|
atomic_cmpset_int(volatile u_int *dst, u_int expect, u_int src)
|
2009-10-09 15:51:40 +00:00
|
|
|
{
|
|
|
|
u_char res;
|
|
|
|
|
|
|
|
__asm __volatile(
|
|
|
|
" " MPLOCKED " "
|
|
|
|
" cmpxchgl %2,%1 ; "
|
|
|
|
" sete %0 ; "
|
|
|
|
"1: "
|
|
|
|
"# atomic_cmpset_int"
|
|
|
|
: "=a" (res), /* 0 */
|
|
|
|
"=m" (*dst) /* 1 */
|
|
|
|
: "r" (src), /* 2 */
|
2010-05-20 06:18:03 +00:00
|
|
|
"a" (expect), /* 3 */
|
2009-10-09 15:51:40 +00:00
|
|
|
"m" (*dst) /* 4 */
|
2010-12-18 16:41:11 +00:00
|
|
|
: "memory", "cc");
|
2009-10-09 15:51:40 +00:00
|
|
|
|
|
|
|
return (res);
|
|
|
|
}
|
|
|
|
|
|
|
|
static __inline int
|
2010-05-20 06:18:03 +00:00
|
|
|
atomic_cmpset_long(volatile u_long *dst, u_long expect, u_long src)
|
2009-10-09 15:51:40 +00:00
|
|
|
{
|
|
|
|
u_char res;
|
2002-07-18 15:56:46 +00:00
|
|
|
|
2009-10-09 15:51:40 +00:00
|
|
|
__asm __volatile(
|
|
|
|
" " MPLOCKED " "
|
|
|
|
" cmpxchgq %2,%1 ; "
|
|
|
|
" sete %0 ; "
|
|
|
|
"1: "
|
|
|
|
"# atomic_cmpset_long"
|
|
|
|
: "=a" (res), /* 0 */
|
|
|
|
"=m" (*dst) /* 1 */
|
|
|
|
: "r" (src), /* 2 */
|
2010-05-20 06:18:03 +00:00
|
|
|
"a" (expect), /* 3 */
|
2009-10-09 15:51:40 +00:00
|
|
|
"m" (*dst) /* 4 */
|
2010-12-18 16:41:11 +00:00
|
|
|
: "memory", "cc");
|
2009-10-09 15:51:40 +00:00
|
|
|
|
|
|
|
return (res);
|
|
|
|
}
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
|
2005-09-27 17:39:11 +00:00
|
|
|
/*
|
|
|
|
* Atomically add the value of v to the integer pointed to by p and return
|
|
|
|
* the previous value of *p.
|
|
|
|
*/
|
|
|
|
static __inline u_int
|
|
|
|
atomic_fetchadd_int(volatile u_int *p, u_int v)
|
|
|
|
{
|
|
|
|
|
2006-12-29 14:28:23 +00:00
|
|
|
__asm __volatile(
|
2006-12-29 13:36:26 +00:00
|
|
|
" " MPLOCKED " "
|
2005-09-27 17:39:11 +00:00
|
|
|
" xaddl %0, %1 ; "
|
|
|
|
"# atomic_fetchadd_int"
|
|
|
|
: "+r" (v), /* 0 (result) */
|
|
|
|
"=m" (*p) /* 1 */
|
2010-12-18 16:41:11 +00:00
|
|
|
: "m" (*p) /* 2 */
|
|
|
|
: "cc");
|
2005-09-27 17:39:11 +00:00
|
|
|
return (v);
|
|
|
|
}
|
|
|
|
|
2008-03-16 21:20:50 +00:00
|
|
|
/*
|
|
|
|
* Atomically add the value of v to the long integer pointed to by p and return
|
|
|
|
* the previous value of *p.
|
|
|
|
*/
|
|
|
|
static __inline u_long
|
|
|
|
atomic_fetchadd_long(volatile u_long *p, u_long v)
|
|
|
|
{
|
|
|
|
|
|
|
|
__asm __volatile(
|
|
|
|
" " MPLOCKED " "
|
|
|
|
" xaddq %0, %1 ; "
|
|
|
|
"# atomic_fetchadd_long"
|
|
|
|
: "+r" (v), /* 0 (result) */
|
|
|
|
"=m" (*p) /* 1 */
|
2010-12-18 16:41:11 +00:00
|
|
|
: "m" (*p) /* 2 */
|
|
|
|
: "cc");
|
2008-03-16 21:20:50 +00:00
|
|
|
return (v);
|
|
|
|
}
|
|
|
|
|
2005-07-21 22:35:02 +00:00
|
|
|
#if defined(_KERNEL) && !defined(SMP)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We assume that a = b will do atomic loads and stores. However, on a
|
|
|
|
* PentiumPro or higher, reads may pass writes, so for that case we have
|
|
|
|
* to use a serializing instruction (i.e. with LOCK) to do the load in
|
|
|
|
* SMP kernels. For UP kernels, however, the cache of the single processor
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
* is always consistent, so we only need to take care of compiler.
|
2005-07-21 22:35:02 +00:00
|
|
|
*/
|
|
|
|
#define ATOMIC_STORE_LOAD(TYPE, LOP, SOP) \
|
|
|
|
static __inline u_##TYPE \
|
|
|
|
atomic_load_acq_##TYPE(volatile u_##TYPE *p) \
|
|
|
|
{ \
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
u_##TYPE tmp; \
|
|
|
|
\
|
|
|
|
tmp = *p; \
|
|
|
|
__asm __volatile ("" : : : "memory"); \
|
|
|
|
return (tmp); \
|
2005-07-21 22:35:02 +00:00
|
|
|
} \
|
|
|
|
\
|
|
|
|
static __inline void \
|
|
|
|
atomic_store_rel_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
|
|
|
|
{ \
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
__asm __volatile ("" : : : "memory"); \
|
2005-07-21 22:35:02 +00:00
|
|
|
*p = v; \
|
|
|
|
} \
|
|
|
|
struct __hack
|
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
#else /* !(_KERNEL && !SMP) */
|
2005-07-21 22:35:02 +00:00
|
|
|
|
2005-07-09 12:38:53 +00:00
|
|
|
#define ATOMIC_STORE_LOAD(TYPE, LOP, SOP) \
|
2001-01-14 09:55:21 +00:00
|
|
|
static __inline u_##TYPE \
|
|
|
|
atomic_load_acq_##TYPE(volatile u_##TYPE *p) \
|
|
|
|
{ \
|
|
|
|
u_##TYPE res; \
|
|
|
|
\
|
2006-12-29 13:36:26 +00:00
|
|
|
__asm __volatile(MPLOCKED LOP \
|
2006-12-29 15:29:49 +00:00
|
|
|
: "=a" (res), /* 0 */ \
|
2005-09-15 19:31:22 +00:00
|
|
|
"=m" (*p) /* 1 */ \
|
|
|
|
: "m" (*p) /* 2 */ \
|
2010-12-18 16:41:11 +00:00
|
|
|
: "memory", "cc"); \
|
2001-01-14 09:55:21 +00:00
|
|
|
\
|
|
|
|
return (res); \
|
|
|
|
} \
|
|
|
|
\
|
|
|
|
/* \
|
|
|
|
* The XCHG instruction asserts LOCK automagically. \
|
|
|
|
*/ \
|
|
|
|
static __inline void \
|
|
|
|
atomic_store_rel_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
|
|
|
|
{ \
|
|
|
|
__asm __volatile(SOP \
|
2005-09-15 19:31:22 +00:00
|
|
|
: "=m" (*p), /* 0 */ \
|
2001-01-14 09:55:21 +00:00
|
|
|
"+r" (v) /* 1 */ \
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
: "m" (*p) /* 2 */ \
|
|
|
|
: "memory"); \
|
2003-11-21 03:02:00 +00:00
|
|
|
} \
|
|
|
|
struct __hack
|
2002-07-18 15:56:46 +00:00
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
#endif /* _KERNEL && !SMP */
|
2005-07-21 22:35:02 +00:00
|
|
|
|
2006-12-28 08:15:14 +00:00
|
|
|
#endif /* KLD_MODULE || !__GNUCLIKE_ASM */
|
2001-01-16 00:18:36 +00:00
|
|
|
|
2002-07-17 16:19:37 +00:00
|
|
|
ATOMIC_ASM(set, char, "orb %b1,%0", "iq", v);
|
|
|
|
ATOMIC_ASM(clear, char, "andb %b1,%0", "iq", ~v);
|
|
|
|
ATOMIC_ASM(add, char, "addb %b1,%0", "iq", v);
|
|
|
|
ATOMIC_ASM(subtract, char, "subb %b1,%0", "iq", v);
|
2001-12-18 08:51:34 +00:00
|
|
|
|
2002-07-17 16:19:37 +00:00
|
|
|
ATOMIC_ASM(set, short, "orw %w1,%0", "ir", v);
|
|
|
|
ATOMIC_ASM(clear, short, "andw %w1,%0", "ir", ~v);
|
|
|
|
ATOMIC_ASM(add, short, "addw %w1,%0", "ir", v);
|
|
|
|
ATOMIC_ASM(subtract, short, "subw %w1,%0", "ir", v);
|
2001-12-18 08:51:34 +00:00
|
|
|
|
2002-07-17 16:19:37 +00:00
|
|
|
ATOMIC_ASM(set, int, "orl %1,%0", "ir", v);
|
|
|
|
ATOMIC_ASM(clear, int, "andl %1,%0", "ir", ~v);
|
|
|
|
ATOMIC_ASM(add, int, "addl %1,%0", "ir", v);
|
|
|
|
ATOMIC_ASM(subtract, int, "subl %1,%0", "ir", v);
|
2001-12-18 08:51:34 +00:00
|
|
|
|
2003-05-01 01:05:25 +00:00
|
|
|
ATOMIC_ASM(set, long, "orq %1,%0", "ir", v);
|
|
|
|
ATOMIC_ASM(clear, long, "andq %1,%0", "ir", ~v);
|
|
|
|
ATOMIC_ASM(add, long, "addq %1,%0", "ir", v);
|
|
|
|
ATOMIC_ASM(subtract, long, "subq %1,%0", "ir", v);
|
2000-10-20 07:00:48 +00:00
|
|
|
|
2002-07-17 16:19:37 +00:00
|
|
|
ATOMIC_STORE_LOAD(char, "cmpxchgb %b0,%1", "xchgb %b1,%0");
|
|
|
|
ATOMIC_STORE_LOAD(short,"cmpxchgw %w0,%1", "xchgw %w1,%0");
|
|
|
|
ATOMIC_STORE_LOAD(int, "cmpxchgl %0,%1", "xchgl %1,%0");
|
2003-05-01 01:05:25 +00:00
|
|
|
ATOMIC_STORE_LOAD(long, "cmpxchgq %0,%1", "xchgq %1,%0");
|
2000-10-20 07:00:48 +00:00
|
|
|
|
2001-01-16 00:18:36 +00:00
|
|
|
#undef ATOMIC_ASM
|
2000-10-20 07:00:48 +00:00
|
|
|
#undef ATOMIC_STORE_LOAD
|
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
#ifndef WANT_FUNCTIONS
|
2005-07-09 12:38:53 +00:00
|
|
|
|
|
|
|
/* Read the current value and store a zero in the destination. */
|
2006-12-28 08:15:14 +00:00
|
|
|
#ifdef __GNUCLIKE_ASM
|
2005-07-09 12:38:53 +00:00
|
|
|
|
|
|
|
static __inline u_int
|
|
|
|
atomic_readandclear_int(volatile u_int *addr)
|
|
|
|
{
|
2006-12-29 15:29:49 +00:00
|
|
|
u_int res;
|
2005-07-09 12:38:53 +00:00
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
res = 0;
|
2006-12-29 14:28:23 +00:00
|
|
|
__asm __volatile(
|
2005-07-09 12:38:53 +00:00
|
|
|
" xchgl %1,%0 ; "
|
|
|
|
"# atomic_readandclear_int"
|
2006-12-29 15:29:49 +00:00
|
|
|
: "+r" (res), /* 0 */
|
|
|
|
"=m" (*addr) /* 1 */
|
2005-09-15 19:31:22 +00:00
|
|
|
: "m" (*addr));
|
2005-07-09 12:38:53 +00:00
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
return (res);
|
2005-07-09 12:38:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static __inline u_long
|
|
|
|
atomic_readandclear_long(volatile u_long *addr)
|
|
|
|
{
|
2006-12-29 15:29:49 +00:00
|
|
|
u_long res;
|
2005-07-09 12:38:53 +00:00
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
res = 0;
|
2006-12-29 14:28:23 +00:00
|
|
|
__asm __volatile(
|
2005-07-09 12:38:53 +00:00
|
|
|
" xchgq %1,%0 ; "
|
|
|
|
"# atomic_readandclear_long"
|
2006-12-29 15:29:49 +00:00
|
|
|
: "+r" (res), /* 0 */
|
|
|
|
"=m" (*addr) /* 1 */
|
2005-09-15 19:31:22 +00:00
|
|
|
: "m" (*addr));
|
2005-07-09 12:38:53 +00:00
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
return (res);
|
2005-07-09 12:38:53 +00:00
|
|
|
}
|
|
|
|
|
2006-12-28 08:15:14 +00:00
|
|
|
#else /* !__GNUCLIKE_ASM */
|
2005-07-09 12:38:53 +00:00
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
u_int atomic_readandclear_int(volatile u_int *addr);
|
|
|
|
u_long atomic_readandclear_long(volatile u_long *addr);
|
2005-07-09 12:38:53 +00:00
|
|
|
|
2006-12-28 08:15:14 +00:00
|
|
|
#endif /* __GNUCLIKE_ASM */
|
2005-07-09 12:38:53 +00:00
|
|
|
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
#define atomic_set_acq_char atomic_set_barr_char
|
|
|
|
#define atomic_set_rel_char atomic_set_barr_char
|
|
|
|
#define atomic_clear_acq_char atomic_clear_barr_char
|
|
|
|
#define atomic_clear_rel_char atomic_clear_barr_char
|
|
|
|
#define atomic_add_acq_char atomic_add_barr_char
|
|
|
|
#define atomic_add_rel_char atomic_add_barr_char
|
|
|
|
#define atomic_subtract_acq_char atomic_subtract_barr_char
|
|
|
|
#define atomic_subtract_rel_char atomic_subtract_barr_char
|
|
|
|
|
|
|
|
#define atomic_set_acq_short atomic_set_barr_short
|
|
|
|
#define atomic_set_rel_short atomic_set_barr_short
|
|
|
|
#define atomic_clear_acq_short atomic_clear_barr_short
|
|
|
|
#define atomic_clear_rel_short atomic_clear_barr_short
|
|
|
|
#define atomic_add_acq_short atomic_add_barr_short
|
|
|
|
#define atomic_add_rel_short atomic_add_barr_short
|
|
|
|
#define atomic_subtract_acq_short atomic_subtract_barr_short
|
|
|
|
#define atomic_subtract_rel_short atomic_subtract_barr_short
|
|
|
|
|
|
|
|
#define atomic_set_acq_int atomic_set_barr_int
|
|
|
|
#define atomic_set_rel_int atomic_set_barr_int
|
|
|
|
#define atomic_clear_acq_int atomic_clear_barr_int
|
|
|
|
#define atomic_clear_rel_int atomic_clear_barr_int
|
|
|
|
#define atomic_add_acq_int atomic_add_barr_int
|
|
|
|
#define atomic_add_rel_int atomic_add_barr_int
|
|
|
|
#define atomic_subtract_acq_int atomic_subtract_barr_int
|
|
|
|
#define atomic_subtract_rel_int atomic_subtract_barr_int
|
2009-10-09 15:51:40 +00:00
|
|
|
#define atomic_cmpset_acq_int atomic_cmpset_int
|
|
|
|
#define atomic_cmpset_rel_int atomic_cmpset_int
|
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
2009-10-06 13:45:49 +00:00
|
|
|
|
|
|
|
#define atomic_set_acq_long atomic_set_barr_long
|
|
|
|
#define atomic_set_rel_long atomic_set_barr_long
|
|
|
|
#define atomic_clear_acq_long atomic_clear_barr_long
|
|
|
|
#define atomic_clear_rel_long atomic_clear_barr_long
|
|
|
|
#define atomic_add_acq_long atomic_add_barr_long
|
|
|
|
#define atomic_add_rel_long atomic_add_barr_long
|
|
|
|
#define atomic_subtract_acq_long atomic_subtract_barr_long
|
|
|
|
#define atomic_subtract_rel_long atomic_subtract_barr_long
|
2009-10-09 15:51:40 +00:00
|
|
|
#define atomic_cmpset_acq_long atomic_cmpset_long
|
|
|
|
#define atomic_cmpset_rel_long atomic_cmpset_long
|
2001-01-16 00:18:36 +00:00
|
|
|
|
2005-07-09 12:38:53 +00:00
|
|
|
/* Operations on 8-bit bytes. */
|
2001-01-16 00:18:36 +00:00
|
|
|
#define atomic_set_8 atomic_set_char
|
|
|
|
#define atomic_set_acq_8 atomic_set_acq_char
|
|
|
|
#define atomic_set_rel_8 atomic_set_rel_char
|
|
|
|
#define atomic_clear_8 atomic_clear_char
|
|
|
|
#define atomic_clear_acq_8 atomic_clear_acq_char
|
|
|
|
#define atomic_clear_rel_8 atomic_clear_rel_char
|
|
|
|
#define atomic_add_8 atomic_add_char
|
|
|
|
#define atomic_add_acq_8 atomic_add_acq_char
|
|
|
|
#define atomic_add_rel_8 atomic_add_rel_char
|
|
|
|
#define atomic_subtract_8 atomic_subtract_char
|
|
|
|
#define atomic_subtract_acq_8 atomic_subtract_acq_char
|
|
|
|
#define atomic_subtract_rel_8 atomic_subtract_rel_char
|
|
|
|
#define atomic_load_acq_8 atomic_load_acq_char
|
|
|
|
#define atomic_store_rel_8 atomic_store_rel_char
|
|
|
|
|
2005-07-09 12:38:53 +00:00
|
|
|
/* Operations on 16-bit words. */
|
2001-01-16 00:18:36 +00:00
|
|
|
#define atomic_set_16 atomic_set_short
|
|
|
|
#define atomic_set_acq_16 atomic_set_acq_short
|
|
|
|
#define atomic_set_rel_16 atomic_set_rel_short
|
|
|
|
#define atomic_clear_16 atomic_clear_short
|
|
|
|
#define atomic_clear_acq_16 atomic_clear_acq_short
|
|
|
|
#define atomic_clear_rel_16 atomic_clear_rel_short
|
|
|
|
#define atomic_add_16 atomic_add_short
|
|
|
|
#define atomic_add_acq_16 atomic_add_acq_short
|
|
|
|
#define atomic_add_rel_16 atomic_add_rel_short
|
|
|
|
#define atomic_subtract_16 atomic_subtract_short
|
|
|
|
#define atomic_subtract_acq_16 atomic_subtract_acq_short
|
|
|
|
#define atomic_subtract_rel_16 atomic_subtract_rel_short
|
|
|
|
#define atomic_load_acq_16 atomic_load_acq_short
|
|
|
|
#define atomic_store_rel_16 atomic_store_rel_short
|
|
|
|
|
2005-07-09 12:38:53 +00:00
|
|
|
/* Operations on 32-bit double words. */
|
2001-01-16 00:18:36 +00:00
|
|
|
#define atomic_set_32 atomic_set_int
|
|
|
|
#define atomic_set_acq_32 atomic_set_acq_int
|
|
|
|
#define atomic_set_rel_32 atomic_set_rel_int
|
|
|
|
#define atomic_clear_32 atomic_clear_int
|
|
|
|
#define atomic_clear_acq_32 atomic_clear_acq_int
|
|
|
|
#define atomic_clear_rel_32 atomic_clear_rel_int
|
|
|
|
#define atomic_add_32 atomic_add_int
|
|
|
|
#define atomic_add_acq_32 atomic_add_acq_int
|
|
|
|
#define atomic_add_rel_32 atomic_add_rel_int
|
|
|
|
#define atomic_subtract_32 atomic_subtract_int
|
|
|
|
#define atomic_subtract_acq_32 atomic_subtract_acq_int
|
|
|
|
#define atomic_subtract_rel_32 atomic_subtract_rel_int
|
|
|
|
#define atomic_load_acq_32 atomic_load_acq_int
|
|
|
|
#define atomic_store_rel_32 atomic_store_rel_int
|
|
|
|
#define atomic_cmpset_32 atomic_cmpset_int
|
|
|
|
#define atomic_cmpset_acq_32 atomic_cmpset_acq_int
|
|
|
|
#define atomic_cmpset_rel_32 atomic_cmpset_rel_int
|
|
|
|
#define atomic_readandclear_32 atomic_readandclear_int
|
2005-09-27 17:39:11 +00:00
|
|
|
#define atomic_fetchadd_32 atomic_fetchadd_int
|
2001-01-16 00:18:36 +00:00
|
|
|
|
2005-08-18 14:36:47 +00:00
|
|
|
/* Operations on 64-bit quad words. */
|
|
|
|
#define atomic_set_64 atomic_set_long
|
|
|
|
#define atomic_set_acq_64 atomic_set_acq_long
|
|
|
|
#define atomic_set_rel_64 atomic_set_rel_long
|
|
|
|
#define atomic_clear_64 atomic_clear_long
|
|
|
|
#define atomic_clear_acq_64 atomic_clear_acq_long
|
|
|
|
#define atomic_clear_rel_64 atomic_clear_rel_long
|
|
|
|
#define atomic_add_64 atomic_add_long
|
|
|
|
#define atomic_add_acq_64 atomic_add_acq_long
|
|
|
|
#define atomic_add_rel_64 atomic_add_rel_long
|
|
|
|
#define atomic_subtract_64 atomic_subtract_long
|
|
|
|
#define atomic_subtract_acq_64 atomic_subtract_acq_long
|
|
|
|
#define atomic_subtract_rel_64 atomic_subtract_rel_long
|
|
|
|
#define atomic_load_acq_64 atomic_load_acq_long
|
|
|
|
#define atomic_store_rel_64 atomic_store_rel_long
|
|
|
|
#define atomic_cmpset_64 atomic_cmpset_long
|
|
|
|
#define atomic_cmpset_acq_64 atomic_cmpset_acq_long
|
|
|
|
#define atomic_cmpset_rel_64 atomic_cmpset_rel_long
|
|
|
|
#define atomic_readandclear_64 atomic_readandclear_long
|
|
|
|
|
2005-07-09 12:38:53 +00:00
|
|
|
/* Operations on pointers. */
|
2005-07-15 18:17:59 +00:00
|
|
|
#define atomic_set_ptr atomic_set_long
|
|
|
|
#define atomic_set_acq_ptr atomic_set_acq_long
|
|
|
|
#define atomic_set_rel_ptr atomic_set_rel_long
|
|
|
|
#define atomic_clear_ptr atomic_clear_long
|
|
|
|
#define atomic_clear_acq_ptr atomic_clear_acq_long
|
|
|
|
#define atomic_clear_rel_ptr atomic_clear_rel_long
|
|
|
|
#define atomic_add_ptr atomic_add_long
|
|
|
|
#define atomic_add_acq_ptr atomic_add_acq_long
|
|
|
|
#define atomic_add_rel_ptr atomic_add_rel_long
|
|
|
|
#define atomic_subtract_ptr atomic_subtract_long
|
|
|
|
#define atomic_subtract_acq_ptr atomic_subtract_acq_long
|
|
|
|
#define atomic_subtract_rel_ptr atomic_subtract_rel_long
|
|
|
|
#define atomic_load_acq_ptr atomic_load_acq_long
|
|
|
|
#define atomic_store_rel_ptr atomic_store_rel_long
|
|
|
|
#define atomic_cmpset_ptr atomic_cmpset_long
|
|
|
|
#define atomic_cmpset_acq_ptr atomic_cmpset_acq_long
|
|
|
|
#define atomic_cmpset_rel_ptr atomic_cmpset_rel_long
|
|
|
|
#define atomic_readandclear_ptr atomic_readandclear_long
|
2000-10-20 07:00:48 +00:00
|
|
|
|
2006-12-29 15:29:49 +00:00
|
|
|
#endif /* !WANT_FUNCTIONS */
|
2006-12-29 14:28:23 +00:00
|
|
|
|
|
|
|
#endif /* !_MACHINE_ATOMIC_H_ */
|