fetch_and_add(2) SDK R4.11 fetch_and_add(2)
NAME
fetchandadd - indivisible fetch and add to memory location (88K
Only)
SYNOPSIS
tb0 0,r0,401
DESCRIPTION
Fetchandadd is a extended operation (XOP) that indivisibly fetches
the value of a user memory location and adds to that memory location.
Input registers are:
r2 Address of 32 bit user memory location to be fetched and added
to. This address must be aligned on a 4 byte boundary.
r3 32 bit integer to add to the user memory location.
Return registers are:
r1 Unchanged
r2 Unchanged
r3 Unchanged
r4 Undefined
r5 New value of the memory location
r6 Undefined
r7 Status: 0 means success (memory location was set to the new
value), 1 means some fault occurred when accessing the memory
location.
r8 Old value of the memory location
r9 Undefined
r10 through r31
Unchanged
The value of the memory location pointed to by r2 is read, the value
in r3 is added to it using unsigned arithmetic (no overflow
exceptions are generated), and the result is stored back into the
same memory location. The old and new values of the memory location
are returned. If any fault (including a page fault) occurs when
accessing the memory location, an error code is returned and the
memory location is not modified.
The fetchandadd XOP executes indivisibly with respect to all other
fetchandadd operations running on any processor in the system that
may be going on simultaneously to the same physical memory location.
It does not necessarily execute indivisibly with respect to
fetchandadd operations to other memory locations, or with respect
to other XOPs to the same memory location, or with respect to normal
loads and stores or I/O traffic to the memory location.
While the XOP is being executed, the user process will not be
descheduled, will not page fault, and will not be terminated. If a
fault of any kind (page fault, protection fault, misaligned access
fault, for example) occurs when the XOP references user data, the XOP
terminates and returns an error. User code is responsible for
catching the error, touching the data item so that the fault can be
handled, and then retrying the XOP. The execution time of the XOP is
charged to user mode, not kernel mode. User profiling ticks that
occur while the XOP is in progress are accounted to the instruction
following the trap instruction.
Fetchandadd must be invoked with an assembly language trap
instruction. Typically the trap instruction is done from an assembly
language routine that is linked with the application and called as a
standard subroutine in the high level language in which the
application is written.
EXAMPLE
global fetchandadd
; routine is entered with the memory address in r2 and the
; amount to add in r3. The following "C" statement invokes
; this routine correctly:
;
; int location, amount, oldvalue;
;
; oldvalue = fetchandadd(&location, amount);
;
;
fetchandadd:
tb0 0,r0,401 ; trap to the fetch-and-add xop (#401)
bcnd ne0,r7,fault ; had a data access fault
jmp.n r1 ; back to the caller
or r2,r0,r8 ; old value is function return value
; if a data access fault occurred during the XOP, control will
; come here. A data access fault could just be a page fault,
; or it could be a real error such as a protection violation.
; Hence we do a simple load of the memory location so that
; whatever the fault is, it will occur on the load. If it is
; a page fault, the page fault will be handled by bringing the
; page into memory. If it is a protection fault, an
; appropriate signal will be sent. If the load succeeds (as
; on a page fault), then we try the XOP over again.
fault:
ld r8,r0,r2 ; read memory location. We really
; don't care care where the data goes.
; r8 is convenient.
br fetchandadd; try the XOP again
Note that the above routine is just an example. Applications can and
should modify the routine to get exactly the desired interface. For
example, the new value can be returned instead of the old value by
moving r5 instead of r8 into r2.
SEE ALSO
storeconditional(2).
Licensed material--property of copyright holder(s)