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
When an instruction has two storage 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 oper­
and is fetched before the other operand is fetched.
Similarly, it is unpredictable how much of the result
is processed before it is returned to storage. In the
case of destructively overlapping operands, the por­
tion of the second operand which is common to the
first is not necessarily fetched from storage.
Programming Notes
The independent fetching of a single location for
each of two operands may affect the program execu­
tion in the following situation.
When the same main-storage location is designat­
ed by two operand addresses of an instruction, and a
channel or another CPU causes the contents of the
location to change during execution of the instruc­
tion, the old and new values of the location may be
used simultaneously. For example, comparison of a
field to itself may yield a result other than equal, or EXCLUSIVE-ORing of a field to itself may yield a
result other than zero.
Serialization
All interruptions, and the execution of certain in­
structions, cause serialization of CPU operation.
Execution of a serialization function consists in com­
pleting aU conceptually prior storage accesses by this CPU, as observed by channels and other CPUs, before the conceptually following storage accesses I occur. Sedalization affect.s the order of all accesses
by this CPU to storage and to the key in storage,
except for those associated with DAT -table-entry
fetch.
Serialization is performed by all interruptions and
by the execution of the following instructions:
1. These general instructions: BRANCH ON CONDITION (BCR) with the Rl and R2 fields
containing all ones and all zeros, respectively,
and COMPARE AND SWAP, COMPARE DOUBLE AND SWAP, STORE CLOCK, SUPERVISOR CALL, and TEST AND SET.
2. LOADPSW. 3. PURGE TLB and SET PREFIX, which also
cause the translation-look aside buffer to be
purged.
4. All I/O instructions.
5. The signaling instructions: READ DIRECT,
WR1[TE DIRECT, and SIGNAL PROC­ ESSOR. The sequence of events associated with a serializ-
28 System/370 Principles of Operation ing operation is as follows: All conceptually previous CPU storage accesses
by this CPU are completed, as observed by
channels and other CPUs. This includes all
conceptually previous stores and changes to
keys in storage. The normal function associated with the serial­
izing operation is performed. In the case of
instruction execution, operands are fetched,
and the storing of results is completed. The
exceptions are LPSW and SPX, in which the
operands may be fetched before previous
stores have been completed, and interruptions,
in which the interruption code and associated
fields may be stored prior to the serialization.
The fetching of the serializing instruction oc­
curs before the execution of the instruction and
may precede the execution of previous instruc­
tions, but may not precede the completion of
the previous serializing operation. In the case
of an interruption, the old PSW, the interrup­
tion code, and other information, if any, are
stored, and the new PSW is fetched. Finally, instruction fetch and operand accesses
for conceptually subsequent operations may
continue.
A serializing function affects the order of storage
accesses that are under the control of the CPU in
which the serializing function takes place. It does
not affect the order of storage accesses caused by a
program in a channel or another CPU. Programming Notes
The following are some effects of a serializing opera­
tion:
1. When an instruction changes the contents of a
storage lo-cation that is used as a source of a
following instruction and when different ad­
dresses are used to designate the location for
storing the result and fetching the instruction, a
serializing operation following the change en­
sures that the modified instruction is executed.
2. When a serializing operation takes place, chan­
nels and any other CPU observe instruction
and operand fetching and result storing to take
place in the order established by the serializing
operation.
Storing into a location from which a serializing
instruction is fetched-does not necessarily affect the
execution of the serializing instruction unless a seri­
alizing function has been performed after the storing
and before the execution of the serializing instruc­
tion.
Previous Page Next Page