711 lines
32 KiB
Plaintext
711 lines
32 KiB
Plaintext
|
|
+------------------------------------------------------------------------------+
|
|
| |
|
|
| |
|
|
| M o d u l a - 2 * Programming Environment |
|
|
| |
|
|
| created by |
|
|
| |
|
|
| Thomas Gauweiler, Stefan U. Haenssgen, Ernst A. Heinz |
|
|
| Paul Lukowicz, Hendrik Mager, Michael Philippsen |
|
|
| |
|
|
| email: msc@ira.uka.de |
|
|
| |
|
|
| |
|
|
| registration email: ipdm2s@ira.uka.de |
|
|
| |
|
|
| |
|
|
| Institute for Program Structures and Data Organization (IPD) |
|
|
| Department of Informatics |
|
|
| University of Karlsruhe |
|
|
| F.R. Germany |
|
|
| |
|
|
| April 10, 1994 |
|
|
| |
|
|
| |
|
|
+------------------------------------------------------------------------------+
|
|
|
|
+------------------------------------------------------------------------------+
|
|
| |
|
|
| |
|
|
| IPD Modula-2* Non - commercial License |
|
|
| |
|
|
| IPD Modula-2* is distributed by the Institute for Program Structures and |
|
|
| Data Organization (hereafter called "IPD") from the Dept. of Informatics |
|
|
| at the University of Karlsruhe, a public institution in the German federal |
|
|
| state of Baden-Wuerttemberg. IPD hereby grants to you a non-transferable, |
|
|
| non-exclusive, royalty free worldwide license to use, copy, modify, |
|
|
| prepare integrated and derivative works of, and distribute IPD Modula-2* |
|
|
| for non-commercial purposes, subject to your agreement to the following |
|
|
| terms and conditions: |
|
|
| |
|
|
| - The IPD Modula-2* Non-commercial License shall be included in the code |
|
|
| and must be retained in all copies of IPD Modula-2* (full or partial; |
|
|
| original, modified, derivative, or otherwise). |
|
|
| |
|
|
| - You acquire no ownership right, title, or interest in IPD Modula-2* |
|
|
| except as provided herein. |
|
|
| |
|
|
| - You agree to make available to IPD all improvements, enhancements, |
|
|
| extensions, and modifications to IPD Modula-2* which are made by you or |
|
|
| your sublicensees and distributed to others and hereby grant to IPD an |
|
|
| irrevocable, fully paid, worldwide, and non-exclusive license under |
|
|
| your intellectual property rights, including patent and copyright, to |
|
|
| use and sublicense, without limititation, these modifications. |
|
|
| |
|
|
| - IPD Modula-2* is a research work which is provided ``as is''. IPD and |
|
|
| its contributors herewith disclaim all warranties with regard to this |
|
|
| software, including all implied warranties of merchantability and |
|
|
| fitness of purpose. In no event shall IPD or any of its contributors be |
|
|
| liable for any special, direct, indirect, or consequential damages or |
|
|
| any damages whatsoever resulting from loss of use, data, or profits, |
|
|
| whether in an action of contract, negligence, or other tortious action, |
|
|
| arising out of or in connection with the use or performance of this |
|
|
| software. |
|
|
| |
|
|
| |
|
|
+------------------------------------------------------------------------------+
|
|
|
|
|
|
|
|
+------------------------------------------------------------------------------+
|
|
| |
|
|
| |
|
|
| I P D M o d u l a - 2 * M a n u a l |
|
|
| |
|
|
| Part I --- General Topics |
|
|
| |
|
|
| |
|
|
| written by Ernst A. Heinz |
|
|
| |
|
|
| |
|
|
+------------------------------------------------------------------------------+
|
|
|
|
|
|
+---------+
|
|
| Credits |
|
|
+---------+
|
|
|
|
The Modula-2* environment was developed at the Institute for Program Structures
|
|
and Data Organization (IPD), Department of Informatics, University of Karlsruhe,
|
|
F.R. Germany. During the long time of its creation the IPD Modula-2* system
|
|
engaged many people as the following list of kernel contributors demonstrates:
|
|
|
|
- Thomas Gauweiler (distribution, documentation, msmfg, test suite)
|
|
- Stefan U. Haenssgen (debugger, msXDW, xmsp)
|
|
- Ernst A. Heinz (compiler, demos, documentation, drivers, libraries)
|
|
- Paul Lukowicz (compiler, demos)
|
|
- Hendrik Mager (semantic analysis)
|
|
- Michael Philippsen (benchmarks, compiler, test suite)
|
|
|
|
We thank Walter F. Tichy and Christian G. Herter for their initial definition
|
|
of the Modula-2* language extensions.
|
|
|
|
Furthermore, Juergen Fritsch deserves due credits for his corrections and
|
|
extensions of the Modula-2* parallel libraries "msEnum", "msReduce", and
|
|
"msScan" --- thank you, Juergen!
|
|
|
|
|
|
+---------------+
|
|
| Functionality |
|
|
+---------------+
|
|
|
|
We have experienced our Modula-2* system to be a very useful tool for research,
|
|
education, and even large scale program development.
|
|
|
|
The outstanding advantages of the IPD Modula-2* system follow from its unique
|
|
support of explicitly parallel high-level language constructs on a variety of
|
|
parallel and sequential machines. This and the fact that it does not cost
|
|
anything if solely used for research and/or educational purposes, make our
|
|
Modula-2* system an attractive and valuable platform for classes and courses in
|
|
parallel programming. The Modula-2* parallel libraries "msEnum", "msReduce", and
|
|
"msScan", included in the system with complete source codes, surely add to this
|
|
attraction. These libraries efficiently implement various primitive parallel
|
|
operations like reductions and scans for one-dimensional arrays.
|
|
|
|
But the IPD Modula-2* system is n o t only directed towards parallel
|
|
programming. Beside its explicitly parallel features, it is a complete
|
|
sequential Modula-2 programming environment offering:
|
|
|
|
- an optimizing compiler translating Modula-2 source programs to portable C,
|
|
- transparent interfacing and full integration of foreign modules written in C,
|
|
- a sophisticated cross-architecture make facility generating standard Unix
|
|
makefiles that trigger the separate compilation of Modula-2 and generated or
|
|
foreign C modules (including automatic re-compilation whenever necessary),
|
|
- X Windows and Emacs development support,
|
|
- and some basic libraries (e.g. "msFIO", "msIO", "msMath", and "msTimer").
|
|
|
|
Although the translation to C causes some complications and disadvantages,
|
|
mainly the missing option of runtime range and index checking, we are still
|
|
convinced that its gains clearly outnumber the associated problems. The central
|
|
arguments for C as an "intermediate" language are availability, portability, and
|
|
resulting native code quality. Furthermore, many real parallel computer systems
|
|
do not even support lower-level languages than C which was quite important for
|
|
our Modula-2* effort.
|
|
|
|
The biggest drawback of the IPD Modula-2* system is the lack of good and
|
|
consistent symbolic debugging support in terms of the language. Naturally, you
|
|
can always use your favourite C debugger to investigate the generated C codes.
|
|
Beside "debugging by value printing" this is what we usually do. It actually
|
|
works fine because the generated C programs resemble the Modula-2 originals very
|
|
closely as for structure, readability, and identifiers. But the scheme is far
|
|
from satisfactory, of course!
|
|
|
|
|
|
+--------------+
|
|
| Availability |
|
|
+--------------+
|
|
|
|
The IPD Modula-2* system is available for 386/486/Pentium PCs running Linux,
|
|
R3000/R4000 DECStations running Ultrix, SPARC Sun-4s or SparcStations running
|
|
SunOS, 680x0 Sun-3s running SunOS, and MasPar MP-1/MP-2 massively parallel
|
|
systems with DECStation frontends running MP-Ultrix.
|
|
|
|
In addition to the above platforms on which the IPD Modula-2* environment
|
|
actually runs, it is able to generate code for 386/486/Pentium PCs running
|
|
BSDI/386 Unix and Kendall Square Research KSR-1/KSR-2 parallel systems
|
|
running KSR-OS. Program development for these target machines is supported
|
|
by an easy-to-use and fully automatic cross-architecture make facility.
|
|
|
|
The following table lists all the machines and their symbolic architecture
|
|
names currently supported by the IPD Modula-2* system.
|
|
|
|
I386 = 386/486/Pentium PC running BSDI/386 Unix (sequential)
|
|
KSRP = Kendall Square Research KSR-1/KSR-2 running KSR-OS (parallel)
|
|
KSRS = Kendall Square Research KSR-1/KSR-2 running KSR-OS (sequential)
|
|
LINX = 386/486/Pentium PC running Linux (sequential)
|
|
MASP = MasPar MP-1/MP-2 with DECStation frontend running MP-Ultrix (parallel)
|
|
MIPS = R3000/R4000 DECStation running Ultrix (sequential)
|
|
SUN3 = 680x0 Sun-3 running SunOS (sequential)
|
|
SUN4 = SPARC Sun-4/SparcStation running SunOS (sequential)
|
|
|
|
|
|
+--------------+
|
|
| Distribution |
|
|
+--------------+
|
|
|
|
You can get the IPD Modula-2* distributions for all supported architectures by
|
|
anonymous ftp from "ftp.ira.uka.de" [129.13.10.90] in the directory
|
|
"pub/programming/modula2star". Please do not forget to use binary mode when
|
|
retrieving any of them! Their names and functionalities are listed below.
|
|
|
|
- "ipdm2s-install" (installation script)
|
|
- "ipdm2s.doc.tar" (documentation archive)
|
|
- "ipdm2s.<VERSION>.<ARCH>.tgz" (distribution archives)
|
|
|
|
The IPD Modula-2* distribution contains only binaries. Unfortunately, we cannot
|
|
make the sources of our system publicly available. (:-Considering the state of
|
|
our sources and the many hacks contained therein, this seems to be a wise scheme
|
|
anyhow ...-:) The documentation archive features abundant gzip'ed documentation
|
|
(well, at least sort of) and comes in "tar" format. The distribution archives
|
|
are in gzip'ed "tar" format and consist of:
|
|
|
|
- compiler "msc",
|
|
- symbolic source-level debugger prototype "msdb" (available for SUN4 only),
|
|
- makefile generator "msmfg",
|
|
- main cross-architecture make facilty driver "mm",
|
|
- several useful command scripts (e.g. "mmclean", "msdel", "msrun", "msproj"),
|
|
- graphical X Windows environment panel "xmsp",
|
|
- Emacs elisp-mode "m2s.el" for Modula-2*,
|
|
- parallel libraries "msEnum", "msReduce", and "msScan",
|
|
- some basic libraries (e.g. "msFIO", "msIO", "msMath", "msTimer"), and
|
|
- collected Modula-2* example programs.
|
|
|
|
|
|
+--------------+
|
|
| Registration |
|
|
+--------------+
|
|
|
|
Although IPD Modula-2* does not cost anything if solely used for research and/or
|
|
educational purposes, we ask you to send a registration email to our electronic
|
|
registration secretary "ipdm2s@ira.uka.de". Please clearly state your name and
|
|
current affiliation as well as all archives you retrieved, installed, and intend
|
|
to use. Thank you very much for your co-operation in advance!
|
|
|
|
Keeping such a registration database is advantageous for both you and us. In
|
|
case of bug fixes and updates, we can directly inform each registered user. As
|
|
for funding the future of IPD Modula-2*, evidence of a world-wide user base may
|
|
decide between "life and death".
|
|
|
|
For further information and bug reports please contact the IPD Modula-2* team
|
|
at "msc@ira.uka.de".
|
|
|
|
|
|
+---------------------+
|
|
| Language Extensions |
|
|
+---------------------+
|
|
|
|
The programming language Modula-2* was developed to support high-level and
|
|
machine-independent parallel programming. As described in [1], it embodies the
|
|
following features:
|
|
|
|
- An arbitrary number of processes operate on data in the same s i n g l e
|
|
address space. Note that shared memory is not required. The single address
|
|
space merely permits all memory to be addressed uniformly but not necessarily
|
|
at uniform speed.
|
|
|
|
- Synchronous and asynchronous parallel computations as well as arbitrary
|
|
nestings thereof can be formulated in a totally machine-independent way.
|
|
|
|
- Procedures may be called in any context, sequential or parallel, and at any
|
|
nesting depth. Additional parallel computations can be spawned inside
|
|
procedures (recursive parallelism).
|
|
|
|
- All abstraction mechanisms of Modula-2 are available for parallel programs.
|
|
|
|
Despite its many achievements, Modula-2* extends Modula-2 with just two new
|
|
language constructs of simple and compact nature:
|
|
|
|
1. The distribution of array data may optionally be specified by so-called
|
|
a l l o c a t o r s. These are machine-independent layout hints for the
|
|
compiler without any semantic meaning.
|
|
|
|
Allocator ::= LOCAL | SPREAD | CYCLE | SBLOCK | CBLOCK .
|
|
|
|
ArrayType ::= ARRAY <SimpleType> [<Allocator>]
|
|
{"," <SimpleType> [<Allocator>]} OF <Type> .
|
|
|
|
Date arrays will only be physically distributed over the available processor
|
|
memories if any of their dimensions are decorated with allocators other than
|
|
LOCAL. If no allocator is specified at all it defaults to LOCAL. Therefore,
|
|
the below declarations of B and C are effectively equivalent.
|
|
|
|
VAR A: ARRAY[1..n] SPREAD OF INTEGER;
|
|
B: ARRAY[1..n], [1..n] OF INTEGER;
|
|
C: ARRAY[1..n] LOCAL, [1..n] LOCAL OF INTEGER;
|
|
D: ARRAY[1..n] SBLOCK, [1..n] SBLOCK OF INTEGER;
|
|
|
|
2. To support explicitly parallel computations, Modula-2* introduces the
|
|
F O R A L L statement in a synchronous and an asynchronous version.
|
|
|
|
ForallStatement ::= FORALL <Ident> ":" <SimpleType> IN (PARALLEL | SYNC)
|
|
[ <VariableDeclaration>
|
|
BEGIN ]
|
|
<StatementSequence>
|
|
END .
|
|
|
|
Here, <SimpleType> denotes an enumeration or a possibly non-static subrange,
|
|
i.e. the boundary expressions may contain variables. The FORALL creates as
|
|
many (conceptual) processes as there are elements in <SimpleType>. The
|
|
identifier introduced by the FORALL statement is local to it and serves as a
|
|
runtime constant for every created process. The runtime constant of each
|
|
process is initialized to a unique value of <SimpleType>.
|
|
All processes created by a FORALL obtain private instances of variables
|
|
declared in the optional <VariableDeclaration> part. Then they execute the
|
|
statements in <StatementSequence>. The END of a FORALL imposes a synchroni-
|
|
zation barrier on the participating processes; termination of the whole
|
|
FORALL is delayed until all created processes have finished their execution
|
|
of <StatementSequence>.
|
|
The processes of a synchronous FORALL execute <StatementSequence> in
|
|
lock-step, while they run concurrently in the asynchronous case. Hence, for
|
|
non-overlapping vectors X, Y, Z an asynchronous FORALL statement suffices to
|
|
implement the vector addition X=Y+Z.
|
|
|
|
FORALL i: [1..n] IN PARALLEL
|
|
Z[i] := X[i] + Y[i];
|
|
END;
|
|
|
|
In contrast to the above, parallel modifications of overlapping data
|
|
structures may require synchronization. Here, synchronous FORALLs even allow
|
|
for easy formulation of arbitrary irregular data permutations.
|
|
|
|
FORALL i: [1..n] IN SYNC
|
|
X[i] := X[p(i)];
|
|
END;
|
|
|
|
The above synchronous FORALL permutes vector X according to permutation
|
|
function p(). The synchronous semantics ensure that all RHS elements X[p(i)]
|
|
are read and temporarily stored before any LHS variable X[i] is written.
|
|
The behaviour of branches and loops inside synchronous FORALLs is defined
|
|
with a MSIMD (multiple SIMD) machine in mind. Consequently, Modula-2* does
|
|
not require any synchronization between different branches of synchronous
|
|
CASE or IF statements. The exact synchronous semantics of all Modula-2*
|
|
statements, including nested FORALLs, and the effects of allocator
|
|
declarations are described in [2] and [3].
|
|
To illustrate the syntax and semantics of private variable declarations
|
|
inside FORALLs we close this section with an example of a naively parallel
|
|
matrix multiply combined with a matrix transposition that computes the
|
|
resulting matrix C according to C=trans(A*B).
|
|
|
|
FORALL i: [1..n] IN PARALLEL
|
|
FORALL j: [1..n] IN PARALLEL
|
|
VAR Cij, k: INTEGER;
|
|
BEGIN
|
|
Cij := 0;
|
|
FOR k:=1 TO n DO (* calculate vector product of i-th row *)
|
|
INC(Cij, A[i,k]*B[k,j]); (* of A and j-th column of B in local Cij *)
|
|
END;
|
|
C[j,i] := Cij; (* transposition by storing Cij in C[j,i] *)
|
|
END;
|
|
END;
|
|
|
|
|
|
+------------+
|
|
| Literature |
|
|
+------------+
|
|
|
|
[1] S.U. Haenssgen, E.A. Heinz, P. Lukowicz, M. Philippsen, and W.F. Tichy.
|
|
"The Modula-2* environment for parallel programming."
|
|
In Proceedings of the Working Conference on Programming Models for
|
|
Massively Parallel Computers, Berlin, Germany, September 20-22, 1993.
|
|
(available by anonymous ftp from i41s10.ira.uka.de [129.13.13.110]
|
|
in directory "pub/m2s" as "pmmp93.ps", "pmmp93.ps.gz", or "pmmp93.ps.Z")
|
|
|
|
[2] W.F. Tichy and C.G. Herter.
|
|
"Modula-2*: An extension of Modula-2 for highly parallel,
|
|
portable programs."
|
|
Technical Report No. 4/90, Department of Informatics,
|
|
University of Karlsruhe, January 1990.
|
|
(available by anonymous ftp from i41s10.ira.uka.de [129.13.13.110]
|
|
in directory "pub/m2s" as "m2s90.ps", "m2s90.ps.gz", or "m2s90.ps.Z")
|
|
|
|
[3] J.R. Smith.
|
|
"The design and analysis of parallel algorithms.
|
|
Chapter 3: Modula-2*."
|
|
Oxford University Press, December 1992.
|
|
|
|
[4] M. Philippsen, E.A. Heinz, and P. Lukowicz.
|
|
"Compiling machine-independent parallel programs."
|
|
ACM SIGPLAN Notices, Volume 28, No. 8, pages 99-108, August 1993.
|
|
|
|
[5] M. Philippsen, T.M. Warschko, W.F. Tichy, C.G. Herter, E.A. Heinz,
|
|
and P. Lukowicz.
|
|
"Project Triton: Towards improved programmability of parallel computers."
|
|
In D.J. Lija and P.L. Bird (editors), The Interaction of Compilation
|
|
Technology and Computer Architecture, Kluwer Academic Publishers, 1994.
|
|
|
|
|
|
|
|
+------------------------------------------------------------------------------+
|
|
| |
|
|
| |
|
|
| I P D M o d u l a - 2 * M a n u a l |
|
|
| |
|
|
| Part II --- Using the Software |
|
|
| |
|
|
| |
|
|
| written by Thomas Gauweiler |
|
|
| |
|
|
| |
|
|
+------------------------------------------------------------------------------+
|
|
|
|
|
|
+--------------+
|
|
| Installation |
|
|
+--------------+
|
|
|
|
You get the package with two files: a tar file and the script ipdm2s-install
|
|
1) use ipdm2s-install with two arguments:
|
|
1st: the architecture (eg.SUN4, MIPS)
|
|
2nd: the directory where msc should be installed, further called <MSC_HOME>
|
|
ipdm2s-install untars the files and generates several files and scripts.
|
|
|
|
2) edit the file "architectures" for your system (see below).
|
|
|
|
3) if you want cross compilation, make sure that rlogin doesn't require
|
|
the password. Otherwise rsh breaks with "Permission denied".
|
|
|
|
4) every user has to extend his paths with <MSC_HOME>/bin
|
|
|
|
|
|
+---------------+
|
|
| File Concepts |
|
|
+---------------+
|
|
|
|
The programs "msc" and "msmfg" assume a fixed pre-defined directory structure.
|
|
You can use msproj with the argument for the target architecture to create
|
|
this structure.
|
|
|
|
The suffix of definition modules is .msd and the files are in the directory ./msd.
|
|
The suffix of the main module is .msm, found in ./msm and the suffix of the
|
|
implementation modules is .msi, you can find them in ./msi.
|
|
|
|
./msd and ./msi contain machine independent files. The following files
|
|
depend on the used machine, therefore they are stored in different architecture
|
|
directories.
|
|
|
|
After compiling using the script mm you find the generated definitions
|
|
(*.h) in ./sym/<ARCH>, the generated implementations (*.c) in ./imp/<ARCH>,
|
|
the (by the c-compiler) generated objects (*.o) in ./obj/<ARCH> and last
|
|
but not least the linked binaries in ./bin/<ARCH>.
|
|
The generated makefile is in ./mkf/<ARCH>.
|
|
|
|
At this time there are the following architectures available:
|
|
for sequential: SUN3 for Sun 680x0, SUN4 for Sparc, I386 for BSD386,
|
|
LINX for 386/486/Pentium PC running Linux,
|
|
MIPS for DECstation, KSRS for KSR sequential
|
|
real parallel: MASP for Maspar, KSRP for KSR parallel.
|
|
|
|
The msc compiler binary is available for
|
|
SUN4 for Sparc, MIPS for DECstation, LINX for Linux
|
|
|
|
|
|
+---------------------+
|
|
| Compiling and so on |
|
|
+---------------------+
|
|
|
|
1) create a working directory.
|
|
2) type msproj <ARCH> (ex. msproj SUN4) to create the directory structure.
|
|
3) Copy your Modula-2* sources to ./msd and ./msi, foreign modules (.c)
|
|
to ./imp/<ARCH>, their headers (.h) to ./sym/<ARCH>
|
|
4) if you don't use Xwindows:
|
|
4a) Compile on your own machine for its architecture:
|
|
type <MSC_HOME>/mm <main_module_name>
|
|
4b) If you want cross compiling for architecture <ARCH>:
|
|
type <MSC_HOME>/mm <main_module_name>:<ARCH>
|
|
4c) If you want cross compiling on machine <MACH> for your own architecture
|
|
type <MSC_HOME>/mm <main_module_name>@<MACH>
|
|
4d) If you want cross compiling on machine <MACH> for architecture <ARCH>
|
|
type <MSC_HOME>/mm <main_module_name>@<MACH>:<ARCH> or
|
|
type <MSC_HOME>/mm <main_module_name>:<ARCH>@<MACH>
|
|
4) if you use XWindows type xmsp for a panel, it calls mm.
|
|
"mm" looks on what architecture you are, determine several parameters for "msmfg"
|
|
and invokes it.
|
|
"msmfg" parses your sources, looks for their dependencies and generates a makefile
|
|
"mm" invokes "make" for compiling.
|
|
|
|
If you give "mm" more than one parameter, "mm" passes them as additional parameters
|
|
to "msmfg". Therefore there is no blank between <Module_Name> and :<ARCH> or
|
|
@<MACH> !
|
|
|
|
|
|
+---------+
|
|
| Options |
|
|
+---------+
|
|
|
|
a) common options for "msmfg" and "msc"
|
|
-target_arch <Arch> set the architecture for generated code
|
|
-verbose verbose - control messages
|
|
-help help
|
|
-path add new paths
|
|
-noproject the project dir structure is not used
|
|
-tab set the path for syntax tables
|
|
only for msc developers
|
|
-silent nearly no output is generated
|
|
-msm, -msd, -msi, -sym, set the file extensions for different compiler phases
|
|
-imp, -obj (defaults: .msm, .msd, .msi, .h, .c, .o)
|
|
set in the architecture file
|
|
|
|
b) options only for msmfg
|
|
-source_arch <Arch> necessary for finding the right msc-compiler
|
|
($MSC_HOME/bin/$SOURCE_ARCH/msc.$SOURCE_ARCH)
|
|
-system generate $SYSTEMMODULE.o etc.
|
|
only for msc developer
|
|
-compiler <name> set the value for $CC
|
|
-linker <name> set the value for $LN
|
|
-machine <name> set the value of machine name for rsh command
|
|
-master_mkf <name> for using another master makefile (default: master)
|
|
-debug using debug mode (analog for '-master_mkf master.debug')
|
|
-optimize using optimize mode (analog '-master_mkf master.optimize')
|
|
-profile using profile mode (analog '-master_mkf master.profile')
|
|
-oforc generates -o Option for cc *.c too
|
|
if not set then mv command will be generated
|
|
-rlo remote link only
|
|
-list prints the import structure of your program
|
|
|
|
c) options only for msc
|
|
be careful, they may be obsolete
|
|
-c generate type casts to make programs lint free
|
|
-g1 generate GRL description of the dependence graph
|
|
including only SYNC dependences
|
|
-g2 generate GRL description of the dependence graph
|
|
including pseudo and SYNC dependences
|
|
(pseudo dependences are shown in dotted style)
|
|
-g3 generate GRL description of the dependence graph
|
|
including normalized and SYNC dependences
|
|
(normalized dependences are shown in dashed style)
|
|
-g4 generate GRL description of the dependence graph
|
|
including normalized, pseudo, and SYNC dependences
|
|
(normalized dependences are shown in dashed style,
|
|
pseudo dependences are shown in dotted style)
|
|
-h print help information
|
|
-i generate header files for imported modules
|
|
-ldir specify directory where msc finds its tables
|
|
-m print test output (memory)
|
|
-P specify number of PEs to generate code for
|
|
-r generate runtime checks
|
|
-s print test output (dependence analysis statistics)
|
|
-s1 print test output (SYNC dependences)
|
|
-s2 print test output (pseudo dependences)
|
|
-s0 no sync point optimization
|
|
-q quiet - don't print the header
|
|
-t print test output (time)
|
|
-w suppress warning diagnostics
|
|
-z do not perform subscript analysis
|
|
-_ try to generate code in spite of errors (no direct exit)
|
|
|
|
|
|
|
|
+---------+
|
|
| Scripts |
|
|
+---------+
|
|
|
|
all script work with the schema:
|
|
<script> <programname>[".msm"]":"<ARCH>"@"<MACHINE>
|
|
|
|
If there are others options behind the first one, these are passed through as
|
|
parameters to the invoked programs.
|
|
|
|
|
|
liball
|
|
it generates a main module, which imports all DEFINITION MODULEs in the current
|
|
directory.
|
|
|
|
msdel [<programname>]":"<ARCH>
|
|
msrm [<programname>]":"<ARCH>
|
|
these scripts delete the files in ./sym/ARCH, ./imp/ARCH, ./obj/ARCH, ./bin/ARCH
|
|
msdir use rm in interactive mode. This is essential if you have c-sources
|
|
for foreign modules in ./imp/ARCH
|
|
|
|
|
|
msproj <ARCH>
|
|
creates a directory structure for your project in your current directory. It moves
|
|
source files which already there to the several places.
|
|
|
|
|
|
mm <programname>[".msm"][":"[<ARCH>]]["@"[<MACHINE>]]
|
|
generates a new makefile with "msmfg" for the program and invokes "make" for
|
|
(cross-)compiling and linking
|
|
|
|
|
|
msclean <programname>[".msm"][":"[<ARCH>]]["@"[<MACHINE>]]
|
|
removes all generated files (convex hull). It works similair to "mm", but invokes
|
|
"make" for making target 'clean:'.
|
|
|
|
msrun <programname>[".msm"][":"[<ARCH>]]["@"[<MACHINE>]]
|
|
executes your program. It's only necessary, if the program should run on
|
|
another machine.
|
|
|
|
|
|
xmsp [<programname>[".msm"]][":"[<ARCH>]]["@"[<MACHINE>]]
|
|
X-version for mm, with several features.
|
|
It requires a proper searchpath in path variable of .cshrc. Please make sure
|
|
that it includes <MSC_HOME>/bin
|
|
|
|
|
|
+---------------+
|
|
| Several Files |
|
|
+---------------+
|
|
|
|
.mspath
|
|
this file is searched in <PROJECTDIR>, ~<USER> and <MSC_HOME> (in this order).
|
|
It contains search paths which will be concatenated. Msmfg and Msc look for the
|
|
sources there.
|
|
|
|
architectures
|
|
it stands in <MSC_HOME> and contains several options for msmfg, which
|
|
depends on the used architecture
|
|
|
|
master.makefiles
|
|
found in <MSC_HOME>/mkf/<ARCH>/. These files are the header of every generated
|
|
makefile and contain several make variables, which only depend on the
|
|
architecture but not the compiled program.
|
|
There is also a special master makefile for debug, optimize and profile mode.
|
|
The master makefile is searched on the paths. If you have a personal version
|
|
in your project directory then this one is used.
|
|
|
|
Xmsp
|
|
it includes informations for the panel.
|
|
|
|
|
|
+--------------------------+
|
|
| Adding New Architectures |
|
|
+--------------------------+
|
|
|
|
a) use the script newarch. It transforms the foreign library modules.
|
|
b) correct the new entry in architectures, especially the new machine name
|
|
c) change the options for the c compiler of the target architecture in the
|
|
files <MSC_HOME>/mkf/<NEW_ARCH>/master*
|
|
d) try to compile the library with
|
|
cd <MSC_HOME>/lib; mm alllib:<NEW_ARCH> -system
|
|
|
|
|
|
+------------------+
|
|
| Network Problems |
|
|
+------------------+
|
|
|
|
Depending on the administration of the network, there may be some trouble with
|
|
mounting. Normally paths like /home/<MACHINE>/<USER> should work, but pwd
|
|
returns extended paths with some stuff like tmp_mnt/ or anything else before the
|
|
common path. Therefore these paths have to be converted by sed. You find the
|
|
essential command in the variable "MM_SED" in ipdm2s-install. If you have
|
|
already installed the package then change the variable in script mm.
|
|
|
|
|
|
+------------+
|
|
| Known Bugs |
|
|
+------------+
|
|
|
|
msc:
|
|
- VAR parameters in procedures are handled as call by value/result (sometimes
|
|
named as copy in / copy out semantic) not as call by reference.
|
|
- The with statement doesn't work with forall loops.
|
|
- Importing only module names may cause msc hanging on an endless loop with
|
|
printing 'Error'.
|
|
To avoid this, you have to import the identifier explicitly with the 'FROM'
|
|
statement, even if you don't use unqualified the identifier.
|
|
|
|
msmfg:
|
|
- if you crosscompile, sometimes your program isn't link by make in the first
|
|
time. In this case, just repeat your command.
|
|
The reason are delays in the NFS.
|
|
|
|
libraries:
|
|
- msFIO for I386:
|
|
breaks with segmentation fault in Close
|
|
- msMath:
|
|
some funktions are not available on all architectures
|
|
- msMath for MIPS:
|
|
log2, exp10, exp2 return wrong values
|
|
|
|
|
|
+----------+
|
|
| Appendix |
|
|
+----------+
|
|
|
|
Module msEnum
|
|
-------------
|
|
allows for efficient enumeration operations
|
|
on arbitrarily large and distributed arrays.
|
|
especially used for parallel extensions.
|
|
|
|
Module msFIO
|
|
------------
|
|
use it for file access
|
|
|
|
Module msIO
|
|
-----------
|
|
all output goes to "stdout", all input comes from "stdin"
|
|
|
|
Module msMath
|
|
-------------
|
|
some math stuff, uses the standard mathlib
|
|
|
|
|
|
Module msRandom
|
|
---------------
|
|
|
|
|
|
Module msReduce
|
|
---------------
|
|
allows for efficient reduction operations on
|
|
arbitrarily large and distributed arrays
|
|
especially used for parallel extensions.
|
|
|
|
|
|
Module msScan
|
|
-------------
|
|
allows for efficient scan operations on
|
|
arbitrarily large and distributed arrays
|
|
especially used for parallel extensions.
|
|
|
|
|
|
Module msTimer
|
|
--------------
|
|
for measuring time
|
|
|
|
|
|
Module msXDW
|
|
------------
|
|
an interface to X-Windows
|