The ModulaTor logo 7KB

The ModulaTor

Oberon-2 and Modula-2 Technical Publication

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.  


The current version of the distribution may be downloaded via anonymous FTP 
from ( in the directory 
\fIpub/soft/oberon/sun3\fP. Release changes will be announced in 


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 <> 
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 

- 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 

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 

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 

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 

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


[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 


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 

 - 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! 



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! 



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
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
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.) 



You can get the IPD Modula-2* distributions for all supported architectures by 
anonymous ftp from "" [] 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. 



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 "". 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 

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 "". 


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. 

         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      ]
                          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];

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)];

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;
        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 *)
        C[j,i] := Cij;              (* transposition by storing Cij in C[j,i] *)



[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 
[] in directory "pub/m2s" as "", "", or 

[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 [] in directory "pub/m2s" as "", 
"", or "") 

[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 


registration email: 

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 

- 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 

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]

Webdesign by, 14-Jul-1998