readme

spice中支持多层次元件模型仿真的可单独运行的插件源码

       O(log p) time.
       If a bit is set in the TYPE matching MSGDBL, MSGINT or MSGCHR then
       XDR is used if communication is over sockets. Note that LENBUF
       presently must have the correct value on the originating and
       receiving nodes. This call may be modified to include an extra
       parameter with the function of LENMES in the RCV() syntax.

   j)  SUBROUTINE SYNCH(TYPE)
       INTEGER TYPE       [input]

       void SYNCH_(long *type)

       Synchronize all processes by exchanging messages of the given
       type in time O(log p).

   k)  SUBROUTINE SETDBG(ONOFF)
       INTEGER ONOFF      [input]

       void SETDBG_(long *onoff)

       Switch debugging output on (ONOFF=1) or off (ONOFF=0). This output
       is useful to trace messages being passed and also to help debug
       the message passing software.

   l)  INTEGER FUNCTION NXTVAL(MPROC)
       INTEGER MPROC      [input]

       long NXTVAL_(long *mproc)

       This call simulates a simple shared counter by communicating with
       a dedicated server process.  It returns the next counter associated
       with a single active loop (0,1,2,...).  MPROC is the number of
       processes actively requesting values.  After the end of the loop
       each process calls NXTVAL(-MPROC) which implements a barrier.
       It is used as follows:

       FORTRAN
       -------------------------
       next = nxtval(mproc)
       do 10 i = 0,big
         if (i .eq. next) then
           ... do work for iteration i
           next = nxtval(mproc)
 	 endif
   10  continue
c
c      call with negative mproc to indicate end of loop ... processes
c      block here until mproc processes have registered completion
c
       junk = nxtval(-mproc)
       -------------------------

       C
       -------------------------
       while ( (i = NXTVAL_(&mproc)) < big ) {
         ... do work for iteration i
       }
       mproc = -mproc;
       (void) NXTVAL_(&mproc);
       -------------------------

       On most UNIX machines the cost is approx. 0.05s per call.  On the
       DELTA and IPSC the cost is less than 0.0003s assuming no contention.
       Clearly the value from NXTVAL can be used to indicate that some
       locally determined no. of iterations should be done as the overhead of
       NXTVAL may be relatively large.  Have a look inside examples/scf.f at
       the function NXTASK() for a simple way of doing this while preserving
       the simple semantics of NXTVAL().

   m)  SUBROUTINE PARERR(CODE)
       INTEGER CODE       [input]

       void ERROR_(char *message, long code)

       Call to request error termination .. it tries to zap all the other
       processes and generally tidy up. The value of code is printed out
       in the error message. 
       C should call ERROR_(char *message, long status).

   n)  SUBROUTINE WAITCOM(NODE)
       INTEGER NODE       [input]

       void WAITCOM_(long *node)

       Wait for all asynchronous communication with node NODE to be
       completed.  NODE=-1 implies all nodes.
       !! Currently this is only applicable to the iPSC and DELTA
       !! where the actual value of NODE is ignored and -1 assumed.

   o)  SUBROUTINE DGOP(TYPE, X, N, OP)
       INTEGER TYPE             [input]
       DOUBLE PRECISION X(N)    [input/output]
       CHARACTER*(*) OP         [input]

       void DGOP_(long *type, double *x, long *n, char *op)
       
       Double Global OPeration.
       X(1:N) is a vector present on each process. DGOP 'sums'
       elements of X accross all nodes using the commutative operator
       OP. The result is broadcast to all nodes. Supported operations
       include '+', '*', 'max', 'min', 'absmax', 'absmin'.
       The use of lowerecase is presently necessary.
       The routine is derived from one by Martyn Guest which in
       turn is modelled after the Intel iPSC GXXXX routines.
       XDR data translation is internally enabled.
 
   p)  SUBROUTINE IGOP(TYPE, X, N, OP)
       INTEGER TYPE             [input]
       INTEGER X(N)             [input/output]
       CHARACTER*(*) OP         [input]

       void IGOP_(long *type, long *x, long *n, char *op)
       
       Integer Global OPeration.
       The integer version of DGOP described above.

   q)  INTEGER FUNCTION MITOB(N)
       INTEGER N                [input]

       long MITOB_(long *n) ... better to use sizeof

       Returns the no. of bytes that N integers (C longs) occupy.

   r)  INTEGER FUNCTION MDTOB(N)
       INTEGER N                [input]

       long MDTOB_(long *n) ... better to use sizeof

       Returns the no. of bytes that N DOUBLE PRECISIONs (C doubles)
       occupy.

   s)  INTEGER FUNCTION MITOD(N)
       INTEGER N                [input]

       long MITOD_(long *n) ... better to use sizeof

       Returns the minimum no. of DOUBLRE PRECSIONs that can hold
       N INTEGERs.

   t)  INTEGER FUNCTION MDTOI(N)
       INTEGER N                [input]

       long MDTOI_(long *n) ... better to use sizeof

       Returns the minimum no. of INTEGERs that can hold
       N DOUBLE PRECISIONs.

   u)  SUBROUTINE PFCOPY(TYPE, NODE0, FILENAME)
       INTEGER TYPE             [input]
       INTEGER NODE0            [input]
       CHARACTER*(*) FILENAME   [input]

       (void) PFILECOPY_(long *type, long *node0, char *filename)

       Process NODE0 has access to the unopened file with name in
       FILENAME the contents of which are to be copied to files
       known to all other processes using messages of type TYPE.
       All processes call PFCOPY() simultaneously, as for BRDCST().
       Since processes may be working in the same directory it
       is advisable to have each process use a unique file name.
       The file is closed at the end of the operation.

       If the data in the file is all of the same type (integer,
       double etc.) AND there is no additional record structure
       (such as that imposed by FORTRAN) TYPE should be set to reflect
       this so that data translation can occur between different
       machines (the blocking is set to accomodate this).
       Otherwise if binary transfer is not meaningful U'll have
       to write your own application specific routine.

    v) INTEGER FUNCTION NICEFTN(INCR)
       INTEGER INCR    [input]

       Portable rapper around nice for FORTRAN users.  See
       the local nice() system call man page for info.
       On the IPSC/DELTA this is a null operation and returns 0.
	

   In addition to the above functions there is a mechanism for
creating a more detailed history of 'events' including timing
information.  PBEGIN(), if compiled with -DEVENTLOG opens the
file 'events.<nodeid>' and PEND() dumps out event information and
closes the file. Imbetween, event logging is disabled by
default and must be enabled by the application.  The 'C'
interface is fully described at the top of file 'evlog.c' and
is also clarified by the FORTRAN interface in evon.c.  The
horrors of portably sending FORTRAN character strings to 'C'
made me simplify the FORTRAN interface.  Have a look in the 
examples codes for usage.

    w) SUBROUTINE EVON()
       SUBROUTINE EVOFF()

       Enable/disable event logging.  Each process logs events to the
       ASCII file 'events.<nodeid>' (with much buffering so for modest
       applications it is only dumped out at the end). This includes
       events such as process creation/termination, message passing etc.
       Event logging may be enabled just around critical sections of code.
       Applications may generate additional information with the following
       (FORTRAN) calls.

    x) SUBROUTINE EVBGIN(INFO)
       SUBROUTINE EVEND(INFO)
       SUBROUTINE EVENT(INFO)
       CHARACTER*(*) INFO

       EVBGIN marks the beginning of an extended event (state?) by logging
       the message in INFO to the event file (along with a timestamp).
       EVEND marks the termination of a state similarly. These calls need
       not be paired for correct functioning, but are in the logical
       interpretation of the event file.
       EVENT logs the message INFO to the file with a timestamp.

Analysis of event files
-----------------------

   A quick glance at an event file will reveal its simple record
structure.  A very crude graphical analysis of this is provided by the
program parse, which interfaces to the UNIX plot utilities through the
program toplot.  Parse and toplot should be made in the normal make
procedure (for the iPSC these need to be compiled and run on the
cubemanager or some more friendly environment).  Crays's UNICOS does
not have the UNIX plot library so you will have to run toplot on a
real UNIX box.  SGI with marvellous (but proprietary) graphics does
not have the plot library either.  Under IBM's AIX the plot library is
there but the filters to display the output are not (except on an IBM
PC printer!). Hah!  On the Titan the plot man page is there but
nothing else! Double hah!

   With no arguments parse reads thru all the event files (event.???)
in the current directory and generates on standard output an ascii
sequence of plot commands that can be turned into a UNIX plot file by
the command toplot.  Parse will also accept two arguments which
specify the range of processes for which event files should be
analysed.

   The UNIX plot file can be viewed by the many standard UNIX plot
filters (the GNU plot2ps package is also useful).

   e.g.  on a Tektronix (e.g. the X xterm Tektronix emulation)

       clear; parse 16 31 | toplot | tek

   On the left of the traces is the process number, on the right is
the percentage of the job duration NOT spent in communication ...
hopefully this is useful time.  The job duration is computed as the
greatest lifetime in the examined eventfiles, and thus the time
percentage also gives an indication of load balance.  A trace consists
of transitions between two levels (lower and upper).  On the lower
level the process is executing user code.  A transition to the upper
level occurs when SND/RCV/WAITCOM are entered. The process then stays
on the upper level until the communication routine is exited whereupon
the trace drops to the lower level.  A page of output looks nice with
about 4-16 traces on it.  There is clearly lots of scope for improving
this.

   The event logging is heavily buffered, but even so, for processes
that are generating a lot of small events (lots of short messages),
significant overhead may be incurred (especially on the iPSC).  To
avoid this in production code simply recompile without -DEVENTLOG
(edit the Makefile, then 'make clean', 'make').


Executing programs in the UNIX environment
------------------------------------------