
The Cray-2 version of the macros and related procedures differ
substantially in some places from those for other machines.
These differences occur not only in the places designated as
"machine dependent", but in some other places as well.
 
The reasons for these differences fall into two major
categories:

    (1)  the different memory model supported by the cray,
         which is discussed in the text, and
    (2)  the fact that we elected to use Cray's "multitasking
         procedure library", as opposed to using more
         primitive C system calls.  For example, the CREATE
	 macro invokes the procedure TSKSTART in the library,
	 rather than doing the call tfork (task fork).  It
	 was decided to use the library routines partially 
	 because they support some error detection (e.g. 
	 deadlock) and partially because documentation for the
	 library procedures was more readily available than
	 documentation for the primitives.

The programs in this directory which demonstrate the Cray
macros and their use are:

    (1)  grid.ch2.U  which demonstrates the ASKFOR monitor 
    (2)  srtest.*.U  three procedures which demosntrate the
         send and receive macros
    (3)  sr2.U  which is a single source file that also
         demonstrates send and receive.  It is included to demo the
         fact that, on the Cray, the master, slave, and procgroups
         do not need to be compiled separately.  Also, it works
         with just two 2 processes (a master and 1 slave).  Thus,
         providing a good example for use when debugging.

There are some new macros for the Cray-2 whose use should be
described:

    (1)  NEWPROC macro should be used in a source file which
    CREATES some slave process.  It declares the slave procedure
    if that procedure is in another source file.  This is
    demonstrated in the srtest.*.U modules.  It is safe to
    include the NEWPROC in files where the slave procedure
    appears in the same source file (e.g. grid.ch2.U), but is
    not necessary in such files (e.g. sr2.U).

    (2)  MODULE_ENV is a new macro that is declared in each
    procedure.  It helps to establish the environment for each
    process.  It is not strictly required to be in every
    procedure, but it is probably safest to include it in
    each.

    (3)  INIT_MODENV  initializes the environment established
    for each process.  It should be executed exactly ONE time
    within each process and should be the first thing executed
    by each slave.  In the master, it should be executed
    immediately after the INITENV.

Some differences in the operation of the old macros:

    (1)  WHOAMI can be executed only once in each process and
    must be executed after all INIT-type macros.  If a slave
    obtains a unique id for itself by WHOAMI(&my_id), then it
    must obtain this value only once and remember it.  The
    value must be passed to any called routines.

    (2)  INITENV and
	 INIT_MODENV each take a parameter "master" indicating
    if the use is in the master process.  These are demonstrated 
    in the sample programs.

Some of the above differences could probably be cleared up by
moving from the multitasking library to the primitives.
Other differecnes would still remain because of the different
memory model.

