The ModulaTor
Ubaye's First Independent Modula-2 & Oberon-2 Journal! Nr. 10, Nov-1994
_______________________________________________________________________
Ulm's Oberon System
Ulm's Oberon System consists of two parts:
1. the compiler for Sun3 workstations and some related tools (makefile
generator + debugger)
2. Ulm's Oberon Library
Note that Ulm's Oberon System gives you a conventional working environment.
Instead of putting a new operating system upon another it may be used like
other compilers and libraries under UNIX.
The compiler supports Oberon but not Oberon-2. There exist some differences
in the language as accepted by newer Zuerich compilers and this one. A
summary about the differences can be found on the attached pages.
The most interesting part of this package is probably the library which covers
following areas:
- abstractions & techniques which enhance OO-programming, e.g. disciplines
- events & exception handling
- input & output
- concurrency & synchronisation
- persistency
- network programming & distributed systems
All these areas are offered on the base of system-independent abstractions.
The library is accompanied by a couple of UNIX-specific implementations of
these abstractions which are written in 100% Oberon. Thus, there is not even a
single line of C code in the library.
The runtime part of the library (also written in Oberon) contains a copying
garbage collector which is capable of returning memory back to UNIX.
All parts of the system are documented by manual pages in the usual UNIX
style. Some areas of the library are covered by tutorials.
Some legal notices
All sources of this distribution (with the exception of a minor part of the
debugger) have been developed at the University of Ulm in Germany which
holds a copyright on it. They may all be freely distributed under the terms of the
GPL and in case of the library under the terms of the LGPL.
FTP-Site
The current version of the distribution may be downloaded via anonymous FTP
from titania.mathematik.uni-ulm.de (134.60.66.21) in the directory
\fIpub/soft/oberon/sun3\fP. Release changes will be announced in
comp.lang.oberon.
Future Work
Currently, we are porting Ulm's Oberon System to the SPARC architecture
under Solaris 2.x.
________________________________________________________________________
Summary About the Oberon Language Differences Between
the Current Implementations of ETH Zuerich and the University
of Ulm
by Andreas Borchert, University of Ulm <borchert@mathematik.uni-ulm.de>
July 1994
Ulm's Oberon Compiler for the m68k processor has been developed in the first
half of 1989 in conformance to [Wirth88] and [Wirth89a]. In September 1989, a
major revision of the Oberon language was published in [Wirth89b]. The main
difference between [Wirth88] and [Wirth89b] is the merge of the definition and
implementation part to one compilation unit. Some additional revisions of minor
importance have been introduced in the report contained in [Reiser92].
Wirth's decision to replace the definition part by a browser tool which extracts
marked declarations from an implementation part is debatable. Even some
members of the ETH Oberon development teams would still prefer the original
variant. There are a couple of reasons for the separation in the tradition of
Modula-2:
- A definition part has its own time stamp and may be frozen and protected.
Compare this with the joined compilation unit: changes of the marked
declarations can be done accidently and are usually detected too late on the
compilation of clients.
- Sometimes, there exist several implementation parts for one definition. It's
easy to check these implementations against a frozen definition but how to do
this without a definition?
- The extraction presented by a browser is not necessarily consistent, i.e. it may
use identifiers which are neither imported nor declared.
- At least the browser of the Zuerich Oberon System doesn't extract any
comments.
For these reasons we still support the original variant. Additionally, some
restrictions (see below) were introduced in [Wirth89b]. Probably, these
restrictions didn't harm the Zuerich Oberon system but allowed to keep the
Zurich Oberon compilers simple. Well, at the time of [Wirth89b] a significant part
of Ulm's Oberon Library was already written which makes use of these features
and there are some good reasons to keep them. At least the *language* (not
necessarily the compiler) is simpler without these restrictions. On the other side,
a lot of minor revisions (mainly syntax changes) were accepted and built into
Ulm's Oberon Compiler.
Please note that despite to the list of differences not even a tiny feature has
been newly added to the Oberon language. It's just a selective adaptation of the
numerous Zuerich revisions.
Language differences
The following list gives the differences between [Reiser92] and [Borchert94]:
References to the Oberon Report are given by -> and followed by section
numbers.
1. -> 4, 11. There are two types of compilation units: definitions and modules.
Consequently, we don't support export marks:
CompilationUnit = module | definition .
definition = DEFINITION ident ";" [ImportList]
DefSequence END ident "." .
DefSequence = { CONST { ConstantDeclaration ";" } |
TYPE { TypeDeclaration ";" } |
VAR { VariableDeclaration ";" } }
{ ProcedureHeading ";" } .
This corresponds to [Wirth88] except that we have adapted the relaxed
declaration ordering of [Wirth89b].
2. -> 10.1. The type of an actual parameter may be an extension of the type of
associated formal parameter even in case of pointer types. This conforms to
[Wirth88].
3. -> 9.1. Records may not be assigned if they contain unknown private parts.
This conforms to [Wirth88].
4. -> 6.4. NEW(p) guarantees on return p to be valid and not equal to NIL. Event
handling gets initiated if there is not enough memory available which usually
leads to program termination. This corresponds to [Wirth88] and avoids
program text which is cluttered up with otherwise necessary tests.
5. -> 12. BYTE belongs to the set of standard types (like INTEGER) and isn't
exported by SYSTEM.
6. -> 12. If ARRAY OF BYTE is given as formal parameter all types of actual
parameters are valid. This holds for value and reference parameters.
7. -> 12. SIZE doesn't belong to the set of standard functions and is exported by
SYSTEM.
8. -> 8.2.2. DIV and MOD are defined even for negative operands on the right
side. Following rules hold in conformance to [Wirth88] and [Wirth89b]:
x = (x DIV y) * y + (x MOD y)
0 <= (x MOD y) < y or y < (x MOD y) <= 0
9. -> 3. Comments may be nested. This conforms to the Zuerich
implementations (see Project Oberon, p. 385) but not to any of the reports.
Differences of the system module
Each Oberon implementor is free to decide about the contents of SYSTEM.
Modules importing SYSTEM are therefore implementation-dependent. Again,
the differences are given in respect to [Reiser92]. More information about the
newly introduced items in SYSTEM can be found in [Borchert94].
1. CC has been removed.
2. New types:
INT16 2-byte-integer; note that INTEGER occupies
4 bytes
ADDRESS LONGINT-compatible address which is
traced by the garbage collector
UNTRACEDADDRESS LONGINT-compatible address which will
be ignored by the garbage collector
3. New procedures:
CRSPAWN(cr) create new coroutine with the calling
procedure as body
CRSWITCH(cr) coroutine switch to cr
HALT(exitcode) causes immediate exit without cleanup
WCLEAR(ptr, n) clears n 4-byte-words
WMOVE(from, to, n) copies n 4-byte-words from `from' to `to'
4. New functions:
TAS(boolvar) atomic test-and-set operation: sets
boolvar to TRUE and returns old value
UNIXCALL(syscall, d0, d1, arg...)
returns BOOLEAN-value and allows
all system calls (except signal & fork)
UNIXFORK(pid) executes fork system call and
returns boolean value
UNIXSIGNAL(signo, p, old, error)
interfaces signal handling system call
References:
[Wirth88] Niklaus Wirth, "The Programming Language Oberon",
Software--Practice and Experience, vol 18, no 7, pp 671-690, July 1988
[Wirth89a] Niklaus Wirth, "Corrections: The Programming Language Oberon",
Software--Practice and Experience, vol 19, no 1, January 1989
[Wirth89b] Niklaus Wirth, "The Programming Language Oberon", Report 111,
ETH Zuerich, Institut fuer Computersysteme, September 1989
[Reiser92] Martin Reiser, Niklaus Wirth, "Programming in Oberon",
Addison-Wesley, New York, 1992
[Borchert94] Andreas Borchert, "Report of Ulm's Oberon Compiler", in Ulm's
Oberon System Reference, pp. 53-60, Universitaet Ulm, February 1994
________________________________________________________________
IPD Modula-2* Manual
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), Faculty 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 Solaris/SunOS, 680x0 Sun-3s running SunOS, and MasPar MP-1/MP-2
massively parallel systems with DECStation front-ends 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 KSR1/KSR2 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 KSR1/KSR2 running KSR-OS (parallel)
KSRS = Kendall Square Research KSR1/KSR2 running KSR-OS (sequential)
LINX = 386/486/Pentium PC running Linux (sequential)
MASP = MasPar MP-1/MP-2 with DECStation frontend running MP-Ultrix (p
arallel)
MIPS = R3000/R4000 DECStation running Ultrix (sequential)
SOL2 = Sun-4/SparcStation running Solaris 2.x = SunOS 5.x (parallel)
SUN3 = Sun-3 680x0 running SunOS (sequential)
SUN4 = Sun-4/SparcStation running SunOS 4.1.x = Solaris 1.x (sequenti
al)
SUN5 = Sun-4/SparcStation running SunOS 5.x = Solaris 2.x (sequential)
(Note: the distributions KSRS & KSRP for KSR-OS and SOL2 & SUN5 for
Solaris 2.x = SunOS 5.x will be available by early December.)
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 distribution 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, 2, 3] 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
allocators. 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
FORALL 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, 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 IEEE
Computer Society Press or 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, Boston /
Dordrecht / London, 1994.
________________________________________________________________________
Modula-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), Faculty of
Informatics, University of Karlsruhe, F.R. Germany,
October 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 Faculty 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.
________________________________________________________________
IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be
taken as working papers and personal rather than organizational statements.
Items are printed at the discretion of the Editor based upon his judgement on
the interest and relevancy to the readership. Letters, announcements, and
other items of professional interest are selected on the same basis. Office of
publication: The Editor of The ModulaTor is Guenter Dotzel; he can be reached
by tel/fax: [removed due to abuse] or by
mailto:[email deleted due to spam]
ModulaWare home page
The ModulaTor download
![[Any browser]](starsbtn.gif){kind=small}
Webdesign by www.otolo.com/webworx,
14-Jul-1998