Browse Prior Art Database

Totally Ordering Compute/Send/Receiver Computations

IP.com Disclosure Number: IPCOM000106658D
Original Publication Date: 1993-Dec-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 4 page(s) / 185K

Publishing Venue

IBM

Related People

Ekanadham, K: AUTHOR [+2]

Abstract

CSRs (Compute/Send/Receive) are programs that execute on separate processors and communicate with each other using send/receive type commands. They are called CSRs because the three basic operations that they perform are COMPUTE(C)/SEND(S)/RECEIVE(R). When a set of CSRs are executed on a Multisequencing in a Single Instruction Stream (MSIS) machine the FETCH/STORE controls can replace the action of the SEND/RECEIVE by either special FETCH/STORE instructions or FETCH/STORE instructions to restricted addresses and the monitoring of these single assignment addresses that are used to coordinate the intercommunication between different Z-CODE segments within the MSIS processor.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 29% of the total text.

Totally Ordering Compute/Send/Receiver Computations

      CSRs (Compute/Send/Receive) are programs that execute on
separate processors and communicate with each other using
send/receive type commands.  They are called CSRs because the three
basic operations that they perform are COMPUTE(C)/SEND(S)/RECEIVE(R).
When a set of CSRs are executed on a Multisequencing in a Single
Instruction Stream (MSIS) machine the FETCH/STORE controls can
replace the action of the SEND/RECEIVE by either special FETCH/STORE
instructions or FETCH/STORE instructions to restricted addresses and
the monitoring of these single assignment addresses that are used to
coordinate the intercommunication between different Z-CODE segments
within the MSIS processor.

      The action of RECEIVE precedes computations that depend on that
RECEIVE for data and the action of a SEND within a CSR follow
computation so as to derive what is to be sent.  On can imagine that
in general, a CSR starts with a RECEIVE and ends with a SEND.
Individual CSRs can be modified by moving the RECEIVE and SEND
relative to the computation.  It is clear that a RECEIVE can be moved
to an earlier point in the CSR while a SEND can be moved to a later
point in the CSR and the following basic CSR constructs will emerge:

       Let |------- or |------C------ denote a series of
computations,

       R represent a single or series of RECEIVE instructions, and

       S represent a single or series of SEND instructions.

          BASIC TYPES OF CSRs

                                                   TYPE

      R|-----------                                  A

       |----------- S                                B

      R|----------- S                                C

      R|----------- S R|----------S  ....  etc        D

      TYPE A and TYPE B CSRs are not common as the need exists for
CSRs to communicate the portion of the overall computation that they
perform to other CSRs.  The computation within a CSR is usually based
on input provided by another CSR.  One might think that the TYPE C
CSR is archetypical and such a CSR will occur when all the RECEIVE
instructions within a CSR have been moved to the top.

      For a CSR with a single RECEIVE and a single SEND we might
easily expect TYPE C if the RECEIVE precedes the SEND.  However in
general when a CSR has multiple SEND and RECEIVE instructions the
ability to move a RECEIVE up-stream or a SEND down-stream may be
limited by the need to interchange the order of a a SEND and RECEIVE.
The freedom to do this without incurring a deadlock is the subject of
this disclosure.

      If a SEND must precede a RECEIVE within a set of CSRs then
there exists a chain of precedence that starts with the SEND and
continuing through the RECEIVE it is int...