SWAP (CDS) cause an interlocked update when
they set condition code o.
The fetch and store accesses associated with an
interlocked-update reference are not necessarily
made contiguously, but restrictions are made on
accesses to the location. The fetch access of an inter­
locked update by another CPU, and all store access­
es by another CPU, are prevented from occurring
between the fetch and the store accesses of an inter- I locked update. CPU fetches which are not part of an
interlocked update, including the fetches of a CS or
CDS instruction which results in condition code 1,
may be made from the location during the interlock
period. ][/0 accesses, either fetch or store, may oc­
cur during the interlock period.
Within the limitations of the above requirements,
the fetch and store accesses associated with an up­
date follow the same rules as the fetches and stores
described in the previous sections.
Programming Notes
When two CPUs attempt to update information at a
common main-storage location by an instruction that
causes fetching and subsequently storing of the up­
dated information, it is possible for both CPUs to
fetch the information and subsequently take the
store access. The change made by the first CPU to
store the result in such a case is lost. Similarly, if
one CPU updates the contents of a field but another CPU makes a store operation to that field between
the fetch and store parts of the update reference, the
effect of the store is lost. If, instead of a store ac­
cess, a CPU makes an interlocked-update reference
to the common storage field between the fetch and
store portions of an update due to another CPU, any
change in the contents produced by the interlocked
update is lost. Only those bytes which are included in the result
field of both operations are considered to be part of
the common main-storage location. However, all bits
within a Gommon byte are considered to be common
even if the bits modified by the two operations do
not overlap. As an example, if one CPU executes the
instruction OR (01) with the value 80 (hex) in the
immediate field and the other CPU executes AND
(NI) with an immediate operand of FE (hex) on the
same byte, one of the updates can be lost.
When the store access is part of an update refer­
ence by the CPU, the execution of the storing is not
contingent on whether the information to be stored
is different from the original contents of the loca­
tion. In particular, the contents of all designated
byte locations are replaced, and, for each byte in the
field, the entire contents of the byte are replaced.
26 System/370 Principles of Operation
An access to store information is performed, for
example, in the following cases:
a. Execution of the OR instruction (01 or OC) with a second operand of all zeros.
b. Execution of OR (OC) with the first-and
second-operand fields coinciding.
c. For those locations of the first operand of
TRANSLATE where the argument and func­
tion values are the same.
The instructions TEST AND SET, COMPARE AND SWAP, and COMPARE DOUBLE AND
SW AP facilitate updating of a common storage field
by two CPUs. In order for the change by either CPU not to be lost, both CPUs must use an instruction
providing an interlocked update. It is possible, how­
ever, for a channel to make an access to the same
storage location between the fetch and store por­
tions of an interlocked update.
Storage-Operand Consistency
Single-Access References With the exception of instructions operating on deci­
mal data, storage-operand references are single­
access references. A fetch reference is said to be a
single-access reference if the result of the operation
comprises a value fetched in a single access to each
byte of the data field. In the case of overlapping
operands, the location may be accessed once for
each operand. A store-type reference is said to be a
single-access reference if a single store access occurs
to each byte location within the data field. An up­
date reference is said to be single-access if the fetch
and store accesses are each single-access.
The storage references associated with the follow­
ing instructions are not necessarily single-access
references: the decimal-feature instructions and the
instructions CONVERT TO BINARY, CONVERT TO DECIMAL, MOVE WITH OFFSET, PACK, and UNPACK. When a storage-operand reference to a location is
not a single-access reference, the contents placed at
a byte location are not necessarily the same for each
store access; thus, intermediate results in a single
byte location may be observed by channels or other CPUs. Programming Note
When multiple fetch accesses are made to a single
byte that is being changed by a channel or another CPU, the result is not necessarily limited to that
which could be obtained by fetching the bits individ­
ually. For example, the process used in MULTIPLY DECIMAL may consist of repetitive additions and
subtractions each of which causes the second oper -
and to be fetched from storage.
Block-Concurrent References
For some references, the accesses to all bytes wit1;lin
a group of contiguous storage locations, or a block,
appear to be concurrent to another CPU, but the
accesses do not necessarily appear to include more
than a byte at a time to I/O. When a fetch-type
reference is concurrent within a block to CPUs, no
store access by another CPU is permitted to the
block during the time that bytes contained in the
block are being fetched. I/O accesses may occur to
the bytes within the block between the fetches.
When a store-type reference is concurrent within a
block to CPUs, no access, either fetch or store, is
permitted to the block during the time that the bytes
within the block are being stored. I/O accesses may
occur to the bytes in the block between the stores.
Consistency Specification
The storage-operand references associated with all S format instructions and all RX format instructions
with the exception of EXECUTE, CONVERT TO DECIMAL, and CONVERT TO BINARY, are
block-concurrent, as observed by all CPUs, if the
operand is addressed on a boundary which is integral
to the size of the operand.
For the instructions COMPARE AND SWAP and COMPARE DOUBLE AND SWAP all accesses
to the storage operand appear to be concurrent as
observed by all CPUs. The under-mask instructions COMPARE LOGI­ CAL CHARACTERS UNDER MASK, INSERT
CHARACTERS UNDER MASK, and STORE CHARACTERS UNDER MASK, and the instruc­
tions LOAD MULTIPLE and STORE MULTIPLE, access the storage operand in a left-to-right direc­
tion, _and (lll bytes accessed within each doubleword to all CPUs to be accessed concurrently.
When destructive overlap does not exist, the oper­
ands of MOVE (MVC) are accessed as follows: The first operand is accessed in a left-to-right
direction, and all bytes accessed within a dou­
bleword appear to all CPUs to be accessed
concurrently. The second operand is accessed left to right,
and all bytes within a doubleword in the sec­
ond operand that are moved into a single dou­
bleword in the first operand appear to all CPUs to be fetched concurrently. Thus, if the
first and second operands begin on the same
byte offset within a doubleword, the second
operand appears to be fetched doubleword­
concurrent. If the offsets within a doubleword
differ by four, the second operand appears to
be fetched word-concurrent.
Destructive overlap is said to exist when the result
location is used as a source after the result has been
stored, assuming processing to be performed a single
byte at a time.
The operands for MOVE LONG and COMPARE LOGICAL LONG appear to all CPUs to be ac­
cessed doubleword-concurrent when both operands
start on doubleword boundaries and are an integral
number of doublewords in length, and, for MOVE LONG, the operands do not overlap.
For EXCLUSIVE OR (XC), when the first and
second operands coincide, the operands appear to all CPUs to be accessed doubleword-concurrent.
Programming Note
It should be noted that, in the case of XC designat­
ing operands which coincide exactly, the bytes with­
in the field may appear to be accessed three times,
by two fetches and one store: once as the fetch por­
tion of the first operand update, once as the second­
operand fetch, and then once as the store portion of
the first-operand update. Each of the three accesses
appears to all CPUs to be doubleword-concurrent,
but the three accesses do not necessarily appear to
occur one immediately after the other.
Relation Between Operand Accesses
Storage-operand fetches associated with one instruc­
tion execution precede all storage-operand refer­
ences for conceptually subsequent instructions. A
storage-operand store specified by one instruction
precedes all storage-operand stores specified by con­
ceptually subsequent instructions, but it does not
necessarily precede storage-operand fetches speci­
fied by conceptually subsequent instructions. How­
ever, a storage-operand store does precede a con­
ceptually subsequent storage-operand fetch to the
same real storage location.
When an instruction has two storage operands
both of which cause fetch references, it is unpredict­
able which operand is fetched first, or how much of
one operand is fetched before the other operand is
fetched. When the two operands overlap, the com­
mon locations may be fetched independently for
each operand.
When an instruction has two storage operands the
first of which causes a store and the second a fetch
reference, it is unpredictable how much of the sec­
ond operand is fetched before the results are stored.
In the case of destructively overlapping operands,
the portion of the second operand which is common
to the first is not necessarily fetched from storage.
Program Execution 27
Previous Page Next Page