Commit Graph

24 Commits

Author SHA1 Message Date
Bruce Evans
d2f22d707a Garbage-collect the "LOCORE" version of MPLOCKED. 2002-02-11 03:41:59 +00:00
John Baldwin
e4e991e117 Allow the ATOMIC_ASM() macro to pass in the constraints on the V parameter
since the char versions need to use either ax, bx, cx, or dx.

Submitted by:	Peter Jeremy (mostly)
Recommended by:	bde
2001-12-18 08:51:34 +00:00
John Baldwin
d900909439 Use newer constraints for atomic_cmpset().
Requested by:	bde
2001-11-12 18:53:45 +00:00
John Baldwin
20a2016a81 Use newer constraints for inline assembly for an operand that is both an
input and an output by using the '+' modifier rather than listing the
operand in both the input and output sections.

Reviwed by:	bde
2001-11-12 16:57:33 +00:00
John Baldwin
2a89a48fbd Allow atomic ops to be somewhat safely used in userland. We always use
lock prefixes in the userland case so that the binaries will work on both
SMP and UP systems.
2001-10-08 20:58:24 +00:00
Mark Murray
d888fc4e73 RIP <machine/lock.h>.
Some things needed bits of <i386/include/lock.h> - cy.c now has its
own (only) copy of the COM_(UN)LOCK() macros, and IMASK_(UN)LOCK()
has been moved to <i386/include/apic.h> (AKA <machine/apic.h>).
Reviewed by:	jhb
2001-02-11 10:44:09 +00:00
John Baldwin
324fffaed1 - Sort of lie and say that %eax is an output only and not an input for the
non-386 atomic_load_acq().  %eax is an input since its value is used in
  the cmpxchg instruction, but we don't care what value it is, so setting
  it to a specific value is just wasteful.  Thus, it is being used without
  being initialized as the warning stated, but it is ok for it to be used
  because its value isn't important.  Thus, we are only sort of lying when
  we say it is an output only operand.
- Add "cc" to the clobber list for atomic_load_acq() since the cmpxchgl
  changes ZF.
2001-01-17 02:15:11 +00:00
John Baldwin
8a6b1c8f54 - Fix atomic_load_* and atomic_store_* to generate functions for atomic.c
that modules can call.
- Remove the old gcc <= 2.8 versions of the atomic ops.
- Resort the order of some things in the file so that there is only
  one #ifdef for KLD_MODULE, and so that all WANT_FUNCTIONS stuff is
  moved to the bottom of the file.
- Remove ATOMIC_ACQ_REL() and just use explicit macros instead.
2001-01-16 00:18:36 +00:00
John Baldwin
9d979d8912 Fix the atomic_load_acq() and atomic_store_rel() functions to properly
implement memory fences for the 486+.  The 386 still uses versions w/o
memory fences as all operations on the 386 are not program ordered.
The 386 versions are not MP safe.
2001-01-14 09:55:21 +00:00
John Baldwin
55d79ad0db The x86 atomic operations are already locked, so they do not need an
additional locked instruction to guarantee a write barrier for the acquire
variants.

Approved by:	dfr
Pointy hat to:	jhb
2000-10-28 00:28:15 +00:00
John Baldwin
ee8f2f372c - Add atomic_cmpset_{acq_,rel_,}_long
- Add in atomic operations for 8-bit, 16-bit, and 32-bit integers
2000-10-25 21:56:16 +00:00
John Baldwin
ccbdd9ee59 - Expand the set of atomic operations to optionally include memory barriers
in most of the atomic operations.  Now for these operations, you can
  use the normal atomic operation, you can use the operation with a read
  barrier, or you can use the operation with a write barrier.  The function
  names follow the same semantics used in the ia64 instruction set.  An
  atomic operation with a read barrier has the extra suffix 'acq', due to
  it having "acquire" semantics.  An atomic operation with a write barrier
  has the extra suffix 'rel'.  These suffixes are inserted between the
  name of the operation to perform and the typename.  For example, the
  atomic_add_int() function now has 3 variants:
  - atomic_add_int() - this is the same as the previous function
  - atomic_add_acq_int() - this function combines the add operation with a
    read memory barrier
  - atomic_add_rel_int() - this function combines the add operation with a
    write memory barrier
- Add 'ptr' to the list of types that we can perform atomic operations
  on.  This allows one to do atomic operations on uintptr_t's.  This is
  useful in the mutex code, for example, because the actual mutex lock is
  a pointer.
- Add two new operations for doing loads and stores with memory barriers.
  The new load operations use a read barrier before the load, and the
  new store operations use a write barrier after the load.  For example,
  atomic_load_acq_int() will atomically load an integer as well as
  enforcing a read barrier.
2000-10-20 07:00:48 +00:00
John Baldwin
b4645202b5 Add atomic_readandclear_int and atomic_readandclear_long. 2000-10-05 22:19:50 +00:00
Poul-Henning Kamp
819e370c3b Introduce atomic_cmpset_int() and atomic_cmpset_long() from SMPng a
few hours earlier than the rest.

The next DEVFS commit needs these functions.

Alpha versions by: dfr
i386 versions by: jakeb

Approved by:    SMPng
2000-09-06 11:21:14 +00:00
David E. O'Brien
25f0103084 When using _asm{} in GCC, one must specify the operand's size if one
specifies the instruction's operation size.  GCC will default to 32-bit
operands reguardless of the prototype (ie, formal parameters' type)
of an inline function.
2000-05-10 01:15:55 +00:00
Peter Wemm
693612eb0b Use the rev 1.1.2.1 code from RELENG_3 for atomic operations rather
than the non-atomic C macros.
1999-10-04 16:24:08 +00:00
Peter Wemm
b87104737a Typo: s/__GNUC_MINOR_/__GNUC_MINOR__/
(__GNUC_MINOR__ on egcs in -current is "91" and is going to be "95" soon)
1999-10-04 16:18:04 +00:00
Eivind Eklund
181d21375b Allow compilation with older versions of GCC, in order to make it possible
to bootstrap and work with -current from older versions of FreeBSD.
1999-10-03 21:15:25 +00:00
Peter Wemm
c3aac50f28 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
Alan Cox
08c40841d8 Create callable (non-inline) versions of the atomic_OP_TYPE functions
that are linked into the kernel.  The KLD compilation options are
changed to call these functions, rather than in-lining the
atomic operations.

This approach makes atomic operations from KLDs significantly
faster on UP systems (though somewhat slower on SMP systems).

PR:		i386/13111
Submitted by:	peter.jeremy@alcatel.com.au
1999-08-18 04:08:31 +00:00
Alan Cox
03e3bc8e62 atomic.h:
Change "void *" to "volatile TYPE *", improving type safety
	and eliminating some warnings (e.g., mp_machdep.c rev 1.106).

cpufunc.h:
	Eliminate setbits.  As defined, it's not precisely correct;
	and it's redundant.  (Use atomic_set_int instead.)

ipl_funcs.c:
	Use atomic_set_int instead of setbits.

systm.h:
	Include atomic.h.

Reviewed by:	bde
1999-07-23 23:45:50 +00:00
Alan Cox
47b8bc92e8 Commit the correct patch, i.e., the one that actually corresponds
to the rev 1.2 log entry.
1999-07-13 06:35:25 +00:00
Alan Cox
e58bb1c453 Changed the implementation of the primitives to guarantee atomicity
with respect to interrupts on UP systems.  (The upgrade from gcc 2.7.x
to egcs 1.1.2 produced at least one non-atomic code sequence in
swap_pager_getpages.)

In addition, the primitives are now SMP-safe, but only on SMPs.  (For
portability between SMPs and UPs, modules are compiled with the SMP-safe
versions.)

Submitted by:	dillon and myself
Reviewed by:	bde
1999-07-13 03:32:17 +00:00
Doug Rabson
069e9bc1b4 Change various syscalls to use size_t arguments instead of u_int.
Add some overflow checks to read/write (from bde).

Change all modifications to vm_page::flags, vm_page::busy, vm_object::flags
and vm_object::paging_in_progress to use operations which are not
interruptable.

Reviewed by: Bruce Evans <bde@zeta.org.au>
1998-08-24 08:39:39 +00:00