

                 The MultiProcessor Simulator  / Experimental Version 1.0


                                by Fe'lix E. Quevedo Stuva


               1.  Introduction

               1.1.  Why a Simulator

                    There are several reasons that justifies a Multiproces-
               sor  Simulator,  instead  of purshising the actual hardware.
               The first reason would be cost, since we assume that a  Mul-
               tiprocessor  Computer  is  expensive.   Well, it is, but not
               much more than a commercial "Supercomputer".  Another reason
               would  be  the  availability of CPU time, but we forget that
               the hardware must be running some kind  of  multiprogramming
               operating system, that allows time sharing. So then, what is
               the need of a simulator if the  reasons  for  not  having  a
               parallel  computer are trivial? Well, we must not forget the
               great diversity of proposed arquitectures and the fact  that
               we do not have at this moment a standard hardware and imple-
               mentation software.

                    The spirit for the simulator design, was to have a tool
               for designing algorithms without having a parallel computer,
               regardless of the model or arquitecture used. This  meant  a
               design   flexible  enough  to  support  the  most  important
               features of most of the  parallel  computer  models:  shared
               memory  and  interprocessor networks. From an academic point
               of view, these two features must be handy to test algorithms
               that requires them.

               1.2.  Outline of the Simulator

                    The simulator allows the user to define an  environment
               where  to  test  parallel algorithms. The user has access to
               the multiprocessor facilities through user functions and  an
               interactive  environment where to execute the programs.  The
               user can define a number of pseudoprocessors, each one  with
               one message queue, and access to a single shared memory seg-
               ment.

                    The message queue defined for a processor  can  contain
               any  type  of  data,  including structures.  The creation of
               shared memory segments is a special feacture reserved for  a
               host programs. The access is public and with concurrent read
               and concurrent write. It is the user the encharged  to  con-
               trol  the  access  to the SMS.  By using a layered approach,
               the user can design the its own parallel computer model.  As
               observed  the  simulator tries not to constrait the applica-
               tion of the user.

                    The simulator runs in  an  UNIX  environment  with  IPC
               facilities.  This is any UNIX release with System V support.
               The number of processors that a user can define  depends  on
               the  value of the UNIX system parameter MAXUPRC, on the sys-
               tem program /sys/param.c.

                    The simulator has been implemented with  all  the  self
               controls  considered at that moment. This does not guarantee
               that a bug could eventually pop.  The only way to avoid such
               inconvinience is the use of the system.

               1.3.  Unix IPC Facilities

                    The Interprocess Communication Facilities of UNIX  Sys-
               tem  V,  is  the  Simulator's lower layer. The two described
               feature of a processor, are actually IPC facilities  with  a
               nice user friendly presentation.

                    The message queue facility operates with  more  options
               than  available  with the simulator. It is important to men-
               tion a constrain in the number of  bytes  that  the  message
               queue  together  can  support is defined on the value ot the
               UNIX system parameters  MSGPOOL,  MSGSIZ,  MSGNMI,  etc;  on
               /sys/h/msg.h.

               1.4.  Suggested Further Implementations

                    There are many upgrades that can be made in this  first
               experimental version:

               a)   improve the setup and execution (mpload,  mprun)  func-
                    tions,

               b)   extend the user library with a set of  prefixed  inter-
                    communication networks;

               c)   extend the user library with a interprocess  synchroni-
                    zation function;

               d)   improve the interactive module, even with  windows  and
                    graphic support;

               e)   research in a  programming  language  interface  layer;
                    etc.

               2.  Installation

                    The Makefile has all the setups  necessary  to  install
               the simulator, just type:

                               make

                    The final product are two file:

               mpsim: 	Interactive Multiprocessor Simulator Manager;

               libmp.a:	 user loading library.

                    To compile a user library just do:

                       cc myfile.c libmp.a [-o myfile] [-lm] ...

               3.  Implementation

                    The simulator has been implemented on  UNIX  C.  It  is
               transportability  has  been  proved between a SUN 3/60 and a
               VaxStation II. In both cases the main modules were  working,
               but with no guarantee of full feature capacity.

                    The implementation consist of the following files:

               a)   mpsim.c: the interactive module.  Contains  the  main()
                    and the  stop handler() functions.

               b)   mplib.c: the common function library. Contains the mpo-
                    pen(),   mptime(),   mpprint(),   mperro(),   mehost(),
                     mplnode() functions.

               c)   mpsys.c: the  system  function  library.  Contains  the
                     handler req(),      handler chl(),      handler sys(),
                     mpinit(),  mpkill(),  mplhost(),  mprun(),  mpstart(),
                     mpstatus(),  mpterm(),  mpwait() functions.

               d)   mpusr.c:  the  user  function  library.  Contains   the
                     pause handler()*,    getpt(),    trchd(),    imhost(),
                    mprnd(), mpdim(), mynode(), load(),  mvstr(),   rcvm(),
                    recv(),  trcv()*,  send(), probe(), crtshm(), attshm(),
                    detshm() slpmsq()* functions. The ones marked with a  *
                    are still on experimental phase.

