Re: Atomic breakage?
On Wed, 17 Jan 2001, Garrett Wollman wrote:
On Tue, 16 Jan 2001 19:10:10 -0800, Alfred Perlstein [EMAIL PROTECTED] said:
Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'?
add longword, add longword with carry? I know it would be pretty
ugly, but it should work, no?
The two bus cycles are independent, so there is a race condition.
OTOH, it's a fairly *unlikely* race condition, and the worst thing
that can happen is statistics that are obviously off by four billion.
(The race only occurs when there is a carry out of the low-order
longword, which is to say, once in every 2**32 operations.)
If they are obviously off by precisely four billion, then they can be
corrected :-).
I have thought of using special overflow handling methods to reduce the
cost of keeping statistics. E.g.:
---
uint32_t counter[2];
/* Low-level code increments only the lower 32 bits of counters. */
atomic_add_32(counter[0]), 1);
/*
* Counter daemon adjusts counters before they get anywhere near
* overflowing. It must run often enough to prevent overflow
* (not very often). This also make the race in the adjustment
* code harmless.
*/
KASSERT(counter[0] 0xC000, "counter got near overflowing");
if (counter[0] 0x8000) {
atomic_subtract_32(counter[0], 0x8000);
++counter[1];
}
/*
* Clients must use code like the following to convert counters
* to values. More locking is required to load counter[0] and
* counter[1] atomically, but this is not a new problem (e.g.,
* atomicity is mostly accidental for accesses via kmem).
*/
counter_value = ((uint64_t)counter[1] 31) | counter[0];
---
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Wed, 17 Jan 2001 14:26:54 +1100, Peter Jeremy [EMAIL PROTECTED] said: To support multiple masters, you need proper locks. On older processors, yes. On processors with the CX8 feature bit set, you can do it without any sort of locking (indeed, this is a primitive that semaphores can be built upon). Consider the following: atomic_increment: ; prologue ; get EA into %esi movl (%esi), %eax movl 4(%esi), %edx 1: movl %eax, %ebx movl %edx, %ecx incl %ebx adcl $0, %ecx cmpxchg8b (%esi); generates a locked bus cycle jne 1 ; epilogue On pre-Pentium processors (which lack the CX8 feature) this sort of sequence is impossible. OTOH, I don't think SMP works on any pre-Pentium processor, so again this degenerates to: pushfl cli incl (%esi) adcl $0, 4(%esi) popfl ...in the non-SMP case. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Tue, 16 Jan 2001 19:10:10 -0800, Alfred Perlstein [EMAIL PROTECTED] said: Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'? add longword, add longword with carry? I know it would be pretty ugly, but it should work, no? The two bus cycles are independent, so there is a race condition. OTOH, it's a fairly *unlikely* race condition, and the worst thing that can happen is statistics that are obviously off by four billion. (The race only occurs when there is a carry out of the low-order longword, which is to say, once in every 2**32 operations.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 17-Jan-01 Garrett Wollman wrote: On Wed, 17 Jan 2001 14:26:54 +1100, Peter Jeremy [EMAIL PROTECTED] said: To support multiple masters, you need proper locks. On older processors, yes. On processors with the CX8 feature bit set, you can do it without any sort of locking (indeed, this is a primitive that semaphores can be built upon). Consider the following: atomic_increment: ; prologue ; get EA into %esi movl (%esi), %eax movl 4(%esi), %edx 1:movl %eax, %ebx movl %edx, %ecx incl %ebx adcl $0, %ecx cmpxchg8b (%esi); generates a locked bus cycle jne 1 ; epilogue On pre-Pentium processors (which lack the CX8 feature) this sort of sequence is impossible. OTOH, I don't think SMP works on any pre-Pentium processor, so again this degenerates to: pushfl cli incl (%esi) adcl $0, 4(%esi) popfl ...in the non-SMP case. Early Pentiums (= P90) don't support CX8 or so I've heard, which make this slightly more complicated, as for a pentium we would have to use a function pointer that we setup during probe. Also, during a SMP boot we would have to panic if CX8 wasn't enabled on all CPU's. -GAWollman -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
In [EMAIL PROTECTED], John Baldwin wrote: Early Pentiums (= P90) don't support CX8 or so I've heard, which make this slightly more complicated, as for a pentium we would have to use a function pointer that we setup during probe. Also, during a SMP boot we would have to panic if CX8 wasn't enabled on all CPU's. P75 (stepping 5): FPU,VME,DE,PSE,TSC,MSR,MCE,CX8 cmpxchg8 was actually introduced with the Pentium processors, as Mr. Wollman already wrote. -- Robert S. F. Drehmel [EMAIL PROTECTED] Real hackers run -current from punchcards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 17-Jan-01 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robert Drehmel writes: In [EMAIL PROTECTED], John Baldwin wrote: Early Pentiums (= P90) don't support CX8 or so I've heard, which make this slightly more complicated, as for a pentium we would have to use a function pointer that we setup during probe. Also, during a SMP boot we would have to panic if CX8 wasn't enabled on all CPU's. P75 (stepping 5): FPU,VME,DE,PSE,TSC,MSR,MCE,CX8 cmpxchg8 was actually introduced with the Pentium processors, as Mr. Wollman already wrote. Either way, it's precense should be determined by looking at the CPUID feature bit. It's the only reliable way. It's expensive though. Ok, after some digging I found out what this particular person was referring to: on Pentiums with stepping 0xc, a cmpxchg8b that crosses a page boundary triggers an illegel opcode fault rather than a page fault if the second page is missing. Woo. :) So as long as we keep all atomically-accessed 64-bit integers within a single page we should be fine for CX8 on all pentiums should we even want 64-bit atomic ops. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Wed, 17 Jan 2001 10:28:03 -0800 (PST), John Baldwin [EMAIL PROTECTED] said: person was referring to: on Pentiums with stepping 0xc, a cmpxchg8b that crosses a page boundary triggers an illegel opcode fault rather than a page fault if the second page is missing. This is (part of) the famous `F00F bug'. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 2001-Jan-17 10:43:10 -0500, Garrett Wollman [EMAIL PROTECTED] wrote: On Wed, 17 Jan 2001 14:26:54 +1100, Peter Jeremy [EMAIL PROTECTED] said: To support multiple masters, you need proper locks. On older processors, yes. On processors with the CX8 feature bit set, you can do it without any sort of locking (indeed, this is a primitive that semaphores can be built upon). This particular sub-thread was specifically discussing the 80386 - as I thought was clear from the context. I am aware of the CMPXCHG8B insn, but it's not relevant to the 386 or 486. On pre-Pentium processors (which lack the CX8 feature) this sort of sequence is impossible. OTOH, I don't think SMP works on any pre-Pentium processor, so again this degenerates to: There are SMP machines using both 386 and 486 processors. There is no support in FreeBSD for SMP on pre-Pentium processors. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Thu, 18 Jan 2001 07:06:09 +1100, Peter Jeremy [EMAIL PROTECTED] said: There are SMP machines using both 386 and 486 processors. There is no support in FreeBSD for SMP on pre-Pentium processors. Yes, I well recall the Sequent. I wish for it to remain a memory. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Mon, 15 Jan 2001, John Baldwin wrote: On 14-Jan-01 Peter Jeremy wrote: And for BDE's benefit - atomic.h is broken for IA32's with 64-bit longs. (I believe that can be fixed for Pentiums and above using CMPXCHG8B, but I can't test the code). The i386 with 64-bit longs doesn't boot from what I hear. Also, long in machine/types.h is 32-bits long. I don't think we need to bother with 64-bit longs. Adding 64-bit atomic ops will be expensive on = 486. It has booted fine for several years. I last built it on 8 Oct 2000. I haven't committed all the bits so it probably doesn't even build in -current. Erm, long isn't in machine/types.h. In machine, only the long limits in machine/limits.h and a few bogus typedefs depend on the size of a long. I bother with 64-bit longs whether I need to or not :-). They get used on i386's mainly in old code and interfaces that don't use typedefs. Hopefully 64-bit scalars will never need to be accessed atomically. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
Bruce Evans wrote: On Mon, 15 Jan 2001, John Baldwin wrote: On 14-Jan-01 Peter Jeremy wrote: And for BDE's benefit - atomic.h is broken for IA32's with 64-bit longs. (I believe that can be fixed for Pentiums and above using CMPXCHG8B, but I can't test the code). The i386 with 64-bit longs doesn't boot from what I hear. Also, long in machine/types.h is 32-bits long. I don't think we need to bother with 64-bit longs. Adding 64-bit atomic ops will be expensive on = 486. It has booted fine for several years. I last built it on 8 Oct 2000. I haven't committed all the bits so it probably doesn't even build in -current. Erm, long isn't in machine/types.h. In machine, only the long limits in machine/limits.h and a few bogus typedefs depend on the size of a long. I bother with 64-bit longs whether I need to or not :-). They get used on i386's mainly in old code and interfaces that don't use typedefs. Hopefully 64-bit scalars will never need to be accessed atomically. Too late. Many statistics in interfaces (i.e. bytes transmitted) are already 64 bit words. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Tue, 16 Jan 2001, Julian Elischer wrote: Bruce Evans wrote: I bother with 64-bit longs whether I need to or not :-). They get used on i386's mainly in old code and interfaces that don't use typedefs. Hopefully 64-bit scalars will never need to be accessed atomically. Too late. Many statistics in interfaces (i.e. bytes transmitted) are already 64 bit words. These don't use atomic operations (hint: no 64-bit atomic operations are implemented on i386's). If they need to be atomic, then they must use locks. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
* Bruce Evans [EMAIL PROTECTED] [010116 19:03] wrote: On Tue, 16 Jan 2001, Julian Elischer wrote: Bruce Evans wrote: I bother with 64-bit longs whether I need to or not :-). They get used on i386's mainly in old code and interfaces that don't use typedefs. Hopefully 64-bit scalars will never need to be accessed atomically. Too late. Many statistics in interfaces (i.e. bytes transmitted) are already 64 bit words. These don't use atomic operations (hint: no 64-bit atomic operations are implemented on i386's). If they need to be atomic, then they must use locks. Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'? add longword, add longword with carry? I know it would be pretty ugly, but it should work, no? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 2001-Jan-16 19:10:10 -0800, Alfred Perlstein [EMAIL PROTECTED] wrote: * Bruce Evans [EMAIL PROTECTED] [010116 19:03] wrote: These don't use atomic operations (hint: no 64-bit atomic operations are implemented on i386's). If they need to be atomic, then they must use locks. Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'? add longword, add longword with carry? I know it would be pretty ugly, but it should work, no? It's not an atomic update because each longword is being updated independently: A reader can access the object between the low word and high word being updated and see an inconsistent result. If you don't need to support multiple bus masters, then the best you can achieve is: "di; addl; adcl; ei" - you don't need the lock prefixes. To support multiple masters, you need proper locks. Since SMP isn't supported on the 80386, as long as you don't to DMA to/from 64-bit objects you can get away with the "di; addl; adcl; ei" sequence. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 14-Jan-01 Peter Jeremy wrote: On 2001-Jan-14 23:02:28 +0200, Mark Murray [EMAIL PROTECTED] wrote: Hi John There seems to be same breakage in the atomic stuff: link_elf: symbol atomic_load_acq_int undefined KLD file random.ko - could not finalize loading I back out the latest commit to sys/i386/include/atomic.h, and things work a bit better (on my laptop). Basically, the problem is that some of the recent commits have broken the interface between sys/i386/include/atomic.h and sys/i386/i386/atomic.c The latter file builds non-inlined versions of the atomic functions defined in atomic.h. This means that atomic.h must be laid out in a suitable manner so that the non-inlined functions are built by atomic.c. (Modules use explicit function calls, rather than inlined atomic functions to remove the need to have distinct UP and SMP versions.) The layout of atomic.h should look like: #ifdef KLD_MODULE #defines expanding to prototypes. #else #defines expanding to inline function definitions #endif List of atomic functions (invoking above macros) Due to incompatibilities between __asm in different versions of gcc, several different versions of various macros (and expansions) are necessary. The old asm should probably die for one thing. The problem is that over time, atomic.h has been expanded and things have gotten a bit confused. Mark's reported breakage is a result of the new atomic_cmpset_int(). This has been defined in the !KLD_MODULE section (but only for new versions of gcc - which should be OK since it'll never be used in conjunction with the old gcc) and a suitable prototype has been inserted in the KLD_MODULE section. The problem is that a pile of #defines have been incorrectly put in this section, rather than outside the KLD_MODULE section. This means that modules are left with dangling references to these functions. Actually, the problem is that I changed atomic_load and atomic_store to be functions for modules instead of inlines because they are now different for I386_CPU. It seems that static versions aren't being compiled of these functions. I'll fix it in a second. atomic_cmpset_* are fine, however. And for BDE's benefit - atomic.h is broken for IA32's with 64-bit longs. (I believe that can be fixed for Pentiums and above using CMPXCHG8B, but I can't test the code). The i386 with 64-bit longs doesn't boot from what I hear. Also, long in machine/types.h is 32-bits long. I don't think we need to bother with 64-bit longs. Adding 64-bit atomic ops will be expensive on = 486. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Atomic breakage?
Hi John There seems to be same breakage in the atomic stuff: link_elf: symbol atomic_load_acq_int undefined KLD file random.ko - could not finalize loading I back out the latest commit to sys/i386/include/atomic.h, and things work a bit better (on my laptop). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 2001-Jan-14 23:02:28 +0200, Mark Murray [EMAIL PROTECTED] wrote:
Hi John
There seems to be same breakage in the atomic stuff:
link_elf: symbol atomic_load_acq_int undefined
KLD file random.ko - could not finalize loading
I back out the latest commit to sys/i386/include/atomic.h, and things
work a bit better (on my laptop).
Basically, the problem is that some of the recent commits have broken
the interface between sys/i386/include/atomic.h and sys/i386/i386/atomic.c
The latter file builds non-inlined versions of the atomic functions
defined in atomic.h. This means that atomic.h must be laid out in a
suitable manner so that the non-inlined functions are built by
atomic.c. (Modules use explicit function calls, rather than inlined
atomic functions to remove the need to have distinct UP and SMP
versions.)
The layout of atomic.h should look like:
#ifdef KLD_MODULE
#defines expanding to prototypes.
#else
#defines expanding to inline function definitions
#endif
List of atomic functions (invoking above macros)
Due to incompatibilities between __asm in different versions of gcc,
several different versions of various macros (and expansions) are
necessary.
atomic.c will include atomic.h with "static" and "__inline" #define'd
to nothing to build a set of atomic functions with external
visibility.
The problem is that over time, atomic.h has been expanded and things
have gotten a bit confused.
Mark's reported breakage is a result of the new atomic_cmpset_int().
This has been defined in the !KLD_MODULE section (but only for new
versions of gcc - which should be OK since it'll never be used in
conjunction with the old gcc) and a suitable prototype has been
inserted in the KLD_MODULE section. The problem is that a pile of
#defines have been incorrectly put in this section, rather than
outside the KLD_MODULE section. This means that modules are
left with dangling references to these functions.
Two (untested) patches are attached, the first is simpler (and
equivalent to the current code), but I think it will report type
mismatches.
And for BDE's benefit - atomic.h is broken for IA32's with 64-bit
longs. (I believe that can be fixed for Pentiums and above using
CMPXCHG8B, but I can't test the code).
Index: atomic.h
===
RCS file: /home/CVSROOT/src/sys/i386/include/atomic.h,v
retrieving revision 1.16
diff -u -r1.16 atomic.h
--- atomic.h2000/10/28 00:28:15 1.16
+++ atomic.h2001/01/14 22:14:31
@@ -151,12 +151,6 @@
}
#endif /* defined(I386_CPU) */
-#defineatomic_cmpset_long atomic_cmpset_int
-#define atomic_cmpset_acq_int atomic_cmpset_int
-#define atomic_cmpset_rel_int atomic_cmpset_int
-#defineatomic_cmpset_acq_long atomic_cmpset_acq_int
-#defineatomic_cmpset_rel_long atomic_cmpset_rel_int
-
#else
/* gcc = 2.8 version */
#define ATOMIC_ASM(NAME, TYPE, OP, V) \
@@ -222,6 +216,12 @@
#undef ATOMIC_ASM
+#define atomic_cmpset_long atomic_cmpset_int
+#define atomic_cmpset_acq_int atomic_cmpset_int
+#define atomic_cmpset_rel_int atomic_cmpset_int
+#defineatomic_cmpset_acq_long atomic_cmpset_acq_int
+#defineatomic_cmpset_rel_long atomic_cmpset_rel_int
+
#ifndef WANT_FUNCTIONS
#define ATOMIC_ACQ_REL(NAME, TYPE) \
static __inline void \
Index: atomic.h
===
RCS file: /home/CVSROOT/src/sys/i386/include/atomic.h,v
retrieving revision 1.16
diff -u -r1.16 atomic.h
--- atomic.h2000/10/28 00:28:15 1.16
+++ atomic.h2001/01/14 22:20:30
@@ -151,12 +151,6 @@
}
#endif /* defined(I386_CPU) */
-#defineatomic_cmpset_long atomic_cmpset_int
-#define atomic_cmpset_acq_int atomic_cmpset_int
-#define atomic_cmpset_rel_int atomic_cmpset_int
-#defineatomic_cmpset_acq_long atomic_cmpset_acq_int
-#defineatomic_cmpset_rel_long atomic_cmpset_rel_int
-
#else
/* gcc = 2.8 version */
#define ATOMIC_ASM(NAME, TYPE, OP, V) \
@@ -223,6 +217,22 @@
#undef ATOMIC_ASM
#ifndef WANT_FUNCTIONS
+
+static __inline long
+atomic_cmpset_long(volatile u_long *dst, u_long exp, u_long src)
+{
+return (atomic_cmpset_int((volatile u_int *)dst, (u_int)exp, (u_int)src));
+}
+
+#define atomic_cmpset_acq_int(dst, exp, src) \
+ atomic_cmpset_int(dst, exp, src)
+#define atomic_cmpset_rel_int(dst, exp, src) \
+ atomic_cmpset_int(dst, exp, src)
+#define atomic_cmpset_acq_long(dst, exp, src) \
+ atomic_cmpset_long(dst, exp, src)
+#define atomic_cmpset_rel_long(dst, exp, src) \
+ atomic_cmpset_long(dst, exp, src)
+
#define ATOMIC_ACQ_REL(NAME, TYPE) \
static __inline void \
atomic_##NAME##_acq_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
Re: Atomic breakage?
On Mon, Jan 15, 2001 at 09:25:45AM +1100, Peter Jeremy wrote: Due to incompatibilities between __asm in different versions of gcc, several different versions of various macros (and expansions) are necessary. Why is that?? The base, and *only* supported compiler for building kernels is GCC 2.95.x, period. GCC 2.8 and 2.7 support should be garbage collected. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 2001-Jan-14 17:05:20 -0800, David O'Brien [EMAIL PROTECTED] wrote:
On Mon, Jan 15, 2001 at 09:25:45AM +1100, Peter Jeremy wrote:
Due to incompatibilities between __asm in different versions of gcc,
several different versions of various macros (and expansions) are
necessary.
Why is that?? The base, and *only* supported compiler for building
kernels is GCC 2.95.x, period. GCC 2.8 and 2.7 support should be garbage
collected.
Feel free to delete it. It was added during the transition period
(when we were migrating away from 2.7), but was never cleaned out.
The (untested) patch is:
Index: atomic.h
===
RCS file: /home/CVSROOT/src/sys/i386/include/atomic.h,v
retrieving revision 1.16
diff -u -r1.16 atomic.h
--- atomic.h2000/10/28 00:28:15 1.16
+++ atomic.h2001/01/15 01:15:39
@@ -84,8 +84,6 @@
* The assembly is volatilized to demark potential before-and-after side
* effects if an interrupt or SMP collision were to occur.
*/
-#if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 9)
-/* egcs 1.1.2+ version */
#define ATOMIC_ASM(NAME, TYPE, OP, V) \
static __inline void \
atomic_##NAME##_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
@@ -157,24 +155,8 @@
#defineatomic_cmpset_acq_long atomic_cmpset_acq_int
#defineatomic_cmpset_rel_long atomic_cmpset_rel_int
-#else
-/* gcc = 2.8 version */
-#define ATOMIC_ASM(NAME, TYPE, OP, V) \
-static __inline void \
-atomic_##NAME##_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
-{ \
- __asm __volatile(MPLOCKED OP\
-: "=m" (*p)\
-: "ir" (V)); \
-} \
- \
-
-#endif
#endif /* KLD_MODULE */
-#if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 9)
-
-/* egcs 1.1.2+ version */
ATOMIC_ASM(set, char, "orb %b2,%0", v)
ATOMIC_ASM(clear,char, "andb %b2,%0", ~v)
ATOMIC_ASM(add, char, "addb %b2,%0", v)
@@ -194,31 +176,6 @@
ATOMIC_ASM(clear,long, "andl %2,%0", ~v)
ATOMIC_ASM(add, long, "addl %2,%0", v)
ATOMIC_ASM(subtract, long, "subl %2,%0", v)
-
-#else
-
-/* gcc = 2.8 version */
-ATOMIC_ASM(set, char, "orb %1,%0", v)
-ATOMIC_ASM(clear,char, "andb %1,%0", ~v)
-ATOMIC_ASM(add, char, "addb %1,%0", v)
-ATOMIC_ASM(subtract, char, "subb %1,%0", v)
-
-ATOMIC_ASM(set, short, "orw %1,%0", v)
-ATOMIC_ASM(clear,short, "andw %1,%0", ~v)
-ATOMIC_ASM(add, short, "addw %1,%0", v)
-ATOMIC_ASM(subtract, short, "subw %1,%0", v)
-
-ATOMIC_ASM(set, int, "orl %1,%0", v)
-ATOMIC_ASM(clear,int, "andl %1,%0", ~v)
-ATOMIC_ASM(add, int, "addl %1,%0", v)
-ATOMIC_ASM(subtract, int, "subl %1,%0", v)
-
-ATOMIC_ASM(set, long, "orl %1,%0", v)
-ATOMIC_ASM(clear,long, "andl %1,%0", ~v)
-ATOMIC_ASM(add, long, "addl %1,%0", v)
-ATOMIC_ASM(subtract, long, "subl %1,%0", v)
-
-#endif
#undef ATOMIC_ASM
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
