User`s guide

How the MACRO Compiler Functions on Different Platforms
2.11 Preserving VAX Atomicity and Granularity
LDL R28,(R1)
Retry: LDL_L R24,4(R1)
ADDL R28,R24,R24
STL_C R24,4(R1)
BEQ fail
.
.
.
fail: BR Retry
Note that, in this code sequence, when the STL_C fails, only the modify operand
is reread before the add. The data (R1) is not reread. This behavior differs
slightly from VAX behavior. In an OpenVMS VAX system, the entire instruction
would execute without interruption; in an OpenVMS Alpha or OpenVMS I64
system, only the modify operand is updated atomically.
As a result, code that requires the read of the data (R1) to be atomic must use
another method, such as a lock, to obtain that level of synchronization.
For this instruction, the compiler generates an Itanium code sequence such as the
following:
ld4 r19 = [r9]
sxt4 r19 = r19
adds r16 = 4, r9
$L4: ld4 r17 = [r16]
mov.m apccv = r17
mov r15 = r17
sxt4 r17 = r17
add r17 = r19, r17
cmpxchg4.acq r17, [r16] = r17
cmp.eq pr0, pr7 = r15, r17
(pr7) br.cond.dpnt.few $L4
Consider another VAX instruction:
MOVL (R1),4(R1)
For this instruction, the compiler generates an Alpha code sequence such as the
following whether or not atomicity preservation was turned on:
LDL R28,(R1)
STL R28,4(R1)
The VAX instruction in this example is atomic on a single VAX CPU, but the
Alpha instruction sequence is not atomic on a single Alpha CPU. Because the
4(R1) operand is a write operand and not a modify operand, the operation is not
made atomic by the use of the LDL_L and STL_C.
On OpenVMS I64 systems, the code sequence would be something like the
following:
ld4 r14 = [r9]
sxt4 r14 = r14
adds r24 = 4, r9
st4 [r24] = r14
Finally, consider a more complex VAX INCL instruction:
INCL @(R1)
For this instruction, the compiler generates an Alpha code sequence such as
the following, when /PRESERVE=ATOMICITY (or .PRESERVE ATOMICITY) is
specified:
How the MACRO Compiler Functions on Different Platforms 2–27