Oberon/compilers

 

Oberon Compilers and Language reference material &#160; Compilers Overview 

Compiler deployment in the maintained ports - Download information Front-end maintainer
 * Enhanced OP2, Paco (Parallel Compiler): Patrik Reali

Difference between OP2 and Paco

Paco differs from OP2 in the following aspects
 * Paco is a completely new compiler written in Active Oberon. It relies on active objects for its execution: every scope is parsed concurrently by a parser object. This is currently not faster, but simplifies the handling of forward references.
 * Language support: no Oberon-2 support and limited support for Oberon-X (semi-dynamic arrays, user defined return types)
 * Intermediate representation: low-level assembler-like representation close to a SSA-form (infinite registers, assigned once).
 * Back-end: hot-pluggable back-ends (currently i386 and StrongARM)

Note concerning the PowerPC compiler for LinuxPPC and MacOs X

In the enhanced PowerPC compiler, introduced in release 2.3.8, the bit order of sets is compatible with the other compilers (x86, SPARC, ...) (SYSTEM.VAL(LONGINT, {0}) = 1).

The old PowerPC compiler, used in MacOberon and PowerOberon (V4) (see below), represents sets in reversed bit order ({0} = 2^31). This makes mixed integer and set operations with type coercions (which are heavily needed in encryption algorithms) unportable. It was probably one of the goals of module BIT to overcome this incompatibility. But the use of module BIT makes algorithms less readable and less efficient.

Compiler deployment in ports no longer updated - Download information Note concerning Slim Binaries, often referred to as "OMI"

OMI is now history and not implemented in the current ETH Oberon system. This very interesting technology was not integrated into the new compiler because we did change the language many times and this required some deep changes to the compiler. The OMI implementation we had (and still have) was optimized for the OP2 parse tree to the extent that changing anything in the parse tree or symbol table would break or cripple it, and it should have been de-optimized first or even rewritten for the new parse tree. Anyway, this is still possible, and it would be interesting, to have somebody take over the OMI code and adapt it to the extended symbol table and parse tree used for Active Oberon.

A number of earlier ports written in the context of the Oberon V4 project are still downloadable though not maintained since: Oberon Language Reports and related Documents
 * MacOberon - Motorola 680x0
 * SPARC-Oberon - Sun SPARC
 * Oberon for Amiga - Motorola 680x0
 * POWERoberon - IBM RISC System/6000
 * HP-Oberon - HP Apollo Series 700
 * Power MacOberon - PowerPC

Note [1]: An Oberon Text file can not be displayed by a conventional browser. In V4 it is displayed with an editor. In ETH Oberon, after opening, the text must be converted to ETH Oberon text by executing WTS.Convert Temp.FTP.Text. The converted text replaces the original one.

Language Examples Compiler Documentation and Resources Books
 * Language FAQ
 * Code Examples
 * Hostess: the Oberon Compiler Test Suite [ hostess.sourceforge.net ]
 * Compiler Options
 * Trap Numbers (Enhanced OP2 and Paco only)
 * ETH Technical Report 125: R. Crélier; OP2: A Portable Oberon Compiler [ PDF. Open the ETH technical reports page and search for "Portable Oberon" ]
 * Compiler Construction by Niklaus Wirth
 * The Art of Assembly Language Programming
 * Assembly language Wikibooks.

Object File Format Intel documentation
 * Native 2.3.6 and earlier [ html | pdf ]
 * Native alpha and beta versions, 2.3.7 Unix Versions [ html | pdf ]
 * Aos/Bluebottle Releases Nov. 17, 06 and later [ html | pdf ]
 * Intel Processor Manuals
 * Built-in Intel386 assembler: documentation (by J. Eloff), instruction list
 * Assembly language in Wikipedia.
 * X86 Assembly Wikibook.

How to write a back-end for a new architecture In our experience, it is relatively easy to write a simple Wirth-like compiler for a new architecture. For example, A. Signer, at that time a student, wrote the compiler back-end for the StrongARM and ported the ETH Oberon system in four months.

The advantage of a Wirth compiler is that it is based on a few fixed code patterns that are generated directly, without first building an internal representation of the program. This simplifies the design significantly.

Paul Reed changed the code pattern procedures to upcalls, which allows him to plug in different code generators.

Of course, it is easier to implement optimizations in a compiler that supports an internal intermediate form, like OP2, but the added complexity only pays off if you actually have time to study and implement the optimization algorithms.

The canonical version is at ftp://ftp.ethoberon.ethz.ch/Oberon/Books/ProjectOberon/ [expired]

''28 Oct 2002 - Copyright &#169; 2002 ETH Z&#252;rich. All rights reserved.''

E-Mail: oberon at lists.inf.ethz.ch

Homepage: http://www.ethoberon.ethz.ch/