Summary About the Oberon Language Differences Between the Current Implementations of ETH Zürich and the University of Ulm


Niklaus Wirth, "The Programming Language Oberon", Software--Practice and Experience, vol 18, no 7, pp 671-690, July 1988
Niklaus Wirth, "Corrections: The Programming Language Oberon", Software--Practice and Experience, vol 19, no 1, January 1989
Niklaus Wirth, "The Programming Language Oberon", Report 111, ETH Zürich, Institut fuer Computersysteme, September 1989
Niklaus Wirth, "The Programming Language Oberon", out of: Martin Reiser, Niklaus Wirth, "Programming in Oberon", Addison-Wesley, New York, 1992
Andreas Borchert, "Report of Ulm's Oberon Compiler", in Ulm's Oberon System Reference, pp. 53-60, Universität Ulm, February 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 [Wirth92].

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:

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 Zürich 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 Zürich revisions.


The following list gives the differences between [Wirth92] 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 Zürich implementations (see Project Oberon, p. 385) but not to any of the reports.


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 [Wirth92]. More information about the newly introduced items in SYSTEM can be found in [Borchert94].
  1. CC has been removed.
  2. New types:
    2-byte-integer; note that INTEGER occupies 4 bytes
    LONGINT-compatible address which is traced by the garbage collector
    LONGINT-compatible address which will be ignored by the garbage collector
  3. New procedures:
    creates new coroutine with the calling procedure as body
    coroutine switch to cr
    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:
    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)
    executes fork system call and returns boolean value
    UNIXSIGNAL(signo, p, old, error)
    interfaces signal handling system call

Andreas Borchert, Sektion Angewandte Informationsverarbeitung, Universität Ulm