Multiple-Access References
In some cases, multiple accesses may be
made to all or some of the bytes of a storage operand. The following cases
may involve multiple-access references:
1. The storage operands of the follow­ ing instructions: CONVERT TO BINA­ RY, CONVERT TO DECIMAL, MOVE INVERSE, MOVE WITH OFFSET, PACK, TRANSLATE, TEST BLOCK, and UNPACK. 2. The stores into that portion of the
first operand of MOVE LONG which is filled with padding bytes.
3. The storage operands of the decimal
instructions.
4. The stores into a DAS-trace entry.
5. The storage operands of vector­
facility instructions.
6. The stores associated
stop-and-store-status PROCESSOR order.
with the SIGNAL When a storage-operand store reference
to a location is not a single-access
reference, the value placed at a byte
location is not necessarily the same for each store access; thus, intermediate
results in a single-byte location may be observed by other CPUs and by channels. Programming Notes 1. When multiple fetch or store
accesses are made to a single byte
that is being changed by another CPU or by a channel, the result is
not necessarily limited to that
which could be obtained by fetching
or storing the bits individually.
For example, the execution of MULTIPLY DECIMAL may consist in
repetitive additions and subtrac­
tions, each of which causes the
second operand to be fetched from
storage and the first operand to be updated in storage.
2. When CPU instructions which make multiple-access references are used
to modify storage locations being
simultaneously accessed by another CPU or by a channel, multiple store
accesses to a single byte by the CPU may result in intermediate values being observed by the other CPU or by the channel. To avoid these intermediate values (for
example, when modifying a CCW chain), only instructions making
single-access references should be
used. Block-Concurrent References
For some references, the accesses to all
bytes within a halfword, word, or
doubleword are specified to appear to be block-concurrent as observed by other CPUs. These accesses do not necessarily
appear to channels to include more than
a byte at a time. The halfword, word,
or doubleword is referred to in this
section as a block. When a fetch-type
reference is specified to appear to be concurrent within a block, no store
access to the block by another CPU is
permitted during the time that bytes
contained in the block are being
fetched. Accesses to the bytes within
the block by channels may occur between
the fetches. When a store-type refer­ ence is specified to appear to be
concurrent within a block, no access to
the block, either fetch or store, is permitted by another CPU during the time
that the bytes within the block are
being stored. Accesses to the bytes in the block by channels may occur between
the stores. Consistency Specification
For all instructions in the S format and
RX format, with the exception of EXECUTE, CONVERT TO DECIMAL, and CONVERT TO BINARY, when the operand is addressed
on a boundary which is integral to the
size of the operand, the storage-operand
references appear to be block-concurrent
as observed by other CPUs. For the instructions COMPARE AND SWAP and COMPARE DOUBLE AND SWAP, all
accesses to the storage operand appear
to be block-concurrent as observed by
other CPUs. The instructions LOAD MULTIPLE and STORE MULTIPLE, when the operand starts on a
word boundary, and the instructions COMPARE LOGICAL CCLC), COMPARE LOGICAL CHARACTERS UNDER MASK, INSERT CHARACTERS UNDER MASK, and STORE CHARACTERS UNDER
MASK access their storage operands in a
left-to-right direction, and all bytes
accessed within each doubleword appear
to be accessed concurrently as observed
by other CPUs. The instructions LOAD CONTROL and STORE CONTROL access the storage operand in a
left-to-right direction, and all bytes
accessed within each word appear to be
accessed concurrently as observed by
other CPUs. When destructive overlap does not exist, the operands of MOVE (MVC), MOVE WITH Chapter 5. Program Execution 5-31

KEY, MOVE TO PRIMARY, and MOVE TO SECONDARY are accessed as follows:
1. The first operand is accessed in a
left-to-right direction, and all bytes accessed within a doubleword
appear to be accessed concurrently
as observed by other CPUs. 2. The second operand is accessed left
to right, and all bytes within a
doubleword in the second operand
that are moved into a single
doubleword in the first operand appear to be fetched concurrently as observed by other CPUs. Thus,
if the first and second operands
begin on the same byte offset with­
in a doubleword, the second operand
appears to be fetched doubleword­
concurrent. If the offsets within a doubleword differ by 4, the second operand appears to be
fetched word-concurrent as observed
by other CPUs. 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 one
byte at a time.
The operands for MOVE LONG appear to be accessed doubleword-concurrent as observed by other CPUs when all of the
following are true: • Both operands start on doubleword
boundaries and are an integral
number of doublewords in length. • The operands do not overlap. • The nonpadding part of the opera­
tion is being executed.
The operands for COMPARE LOGICAL LONG appear to be accessed doubleword­
concurrent as observed by other CPUs whon both operands start on doubleword
boundaries and are an integral number of
doublewords in length.
For EXCLUSIVE OR (XC), the operands are processed in a left-to-right direction,
and, when the first and second operands all bytes accessed within a doubleword appear to be accessed concur­
rently as observed by other CPUs. Programming Note
In the case of EXCLUSIVE OR (XC) desig­ nating operands which coincide exactly, the bytes within the field may appear to be accessed as many as three times, by
two fetches and one store: once as the fetch portion of the first operand
5-32 System/370 Principles of Operation 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 be doubleword-concurrent as observed by
other CPUs, but the three accesses do
not necessarily appear to occur one immediately after the other. One or
both fetch accesses may be omitted since the instruction can be completed without
fetching the operands. RELATION BETWEEN OPERAND ACCESSES
As observed by other CPUs and by chan­
nels, storage-operand fetches associated
with one instruction execution appear to precede all storage-operand references for conceptually subsequent
instructions. A storage-operand store
specified by one instruction appears to
precode all storage-operand stores spec­
ified by conceptually subsequent
instructions, but it does not necessar­
ily precede storage-operand fetches specified by conceptually subsequent
instructions. However, a storage­
operand store appears to precede a conceptually subsequent storage-operand
fetch from the same main-storage
location. When an instruction has two storage
operands both of which cause fetch
references, it is unpredictable which
operand is fetched first, or how much of
one operand is fetched before the other
operand is fetched. When the two oper­
ands overlap, the common locations may be fetched independently for each oper­
and.
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
second 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. When an instruction has two storage
operands the first of which causes an
update reference and the second a fetch reference, it is unpredictable which
operand is fetched first, or how much of
one operand is fetched before the other
operand is fetched. Similarly, it is
unpredictable how much of the result is
processed before it is returned to stor­ age. 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.