[Looking for a book logo 9.5KB]
Click here to see interesting book recommendations!

Oberon System and Compiler Implementations

(OSCI)

[modulAware.com/zel logo]

The table below lists the main features of some currently available Oberon compilers and systems.
One purpose of this features list is to increase Oberon user base. Successful languages have several compiler implementations. By providing a comprehensive comparison together with links to the products' home-pages, this list should help new and experienced Oberon users to locate suitable implementations for education and application development.

If you are a maintainer of an Oberon system or compiler, please send the product's main implementation features to gd at modulaware.com. Don't forget to include the URL of the product's main web-page. Thank you for your contribution.

The list is ordered in the sequence the implementation data was submitted.
Oberon Compiler/System features
Name IDE DML Lib fgs Ref RTD TVboR GC Y2K free src am
AOS V4 * V4 * * * * * *1a *1b 1c *
A2O (DLL) ISO M2 *2a *2b *
XDS 3a (DLL) ISO M2 *3b * * *
OM2 * ISO M2 * 4a
COJ 5a 5b 5c * 5d *
JOB * 6a 6b * 6c 6d *
OOC PROP 7a ? * * *
CP * DML PROP * * * * ? 8a 8b *
OBC 9a * * * *

Oberon-2 compiler pervasive data type sizes in bytes
Name POINTER LONGINT INTEGER SHORTINT CHAR LONGREAL REAL SET BYTE pv PTR ADR()
AOS 8 8 2 1 1 8 4 4 1 8 8 LONGINT
A2O 8/4 8/4 2 1 1 8 4 4 1 8/4 8/4 LONGINT
XDS 4 4 2 1 1 8 4 4 1 4 4 LONGINT
OM2 4 4 2 1 1 8 4 4 1 4 4 LONGINT
COJ 4 4 2 1 2 8 4 4 1 4 4 PTR
JOB 4 8 4 2 2 8 4 4 1 ? ? ?
OOC 4? 4 2 1 1 8 4 4 1 4? 4? LONGINT?
CP 4? 8 4 2 2 n.a. 8 4 1 4? 4? INTEGER?
OBC 4 n/a 4 n/a 1 8 4 4 1 4 n/a n/a

Abbreviations

Number data type hierarchy
Name <SHORT | LONG> navigation constant expressions
AOS SHORTINT <> INTEGER <> LONGINT > REAL <> LONGREAL SHORTINT <= INTEGER <= SIGNED_32 <= SIGNED_64 <= F <= D <= S <= G <= T_FLOATING
A2O
XDS SHORTINT <= INTEGER <= LONGINT <= REAL <= LONGREAL
OM2
COJ
JOB
OOC SHORTINT <> INTEGER <> LONGINT <> HUGEINT < REAL <> LONGREAL SHORTINT <= INTEGER <= LONGINT <= REAL <= LONGREAL
CP BYTE <> SHORTINT <> INTEGER <> LONGINT < SHORTREAL < REAL BYTE <= SHORTINT <= INTEGER <= LONGINT < SHORTREAL <= REAL
OBC INTEGER < REAL <> LONGREAL INTEGER <= REAL <= LONGREAL

Product name list with links and remarks

  1. AOS: 64 bit Oberon System for Compaq OpenVMS Alpha. Download AOS here. (Since 1999, Compaq's OpenVMS Alpha operating system is free for private use; to get a free software license (product authorization key) on-line, follow the OpenVMS hobbyist link at the bottom of this page.)
    • 1a) is year 9999 compliant
    • 1b) free with restricted version of the commercial compiler A2O (limits source code size)
    • 1c) source of applications (modified for 64 bit adressing where necessary) available on request, but without Kernel/System/Modules/RTD/Ref-layer.
    • name and [size in bytes] of additional data types in module SYSTEM: SIGNED_8 [1], SIGNED_16 [2], SIGNED_32 [4], SIGNED_64 [8], ADDRESS_32 [4], ADDRESS_64 [8], F_FLOATING [4], D_FLOATING [8], S_FLOATING [4], G_FLOATING [8], T_FLOATING [8]
    • pervasive types REAL/LONGREAL identical to S/T_FLOATING
    • pervasive type LONGINT identical to SIGNED_64
  2. A2O: 64 bit and 32 bit Oberon-2 Compiler for Compaq OpenVMS Alpha
    • 2a) provides for OpenVMS source-level symbolic run-time debugger.
    • 2a) is year 9999 compliant
    • names of additional data types, see AOS
    • pervasive types REAL/LONGREAL either identical to S/T_FLOATING or F/D_FLOATING
    • pervasive type LONGINT either identical to SIGNED_32 or SIGNED_64
  3. XDS: 32 bit Oberon-2 [and ISO Modula-2] Compiler for PC/WNT/95/98/Linux/OS/2, SunSparc/Solaris, and HP-9000/HP-UX
    • 3a) proprietory IDE (not available unter Unix/Linux/Solaris/HP-UX)
    • 3b) proprietory, symbolic RTD
    • name and [size in bytes] of additional data types in module SYSTEM: BOOL8 [1], BOOL16 [2], BOOL32 [4], INT8 [1], INT16 [2], INT32 [4], INT [4], int [4*] CARD8 [1], CARD16 [2], CARD32 [4], CARD [4], unsigned [4*] SET8 [1], SET16 [2], SET32 [4] REAL32 [4], REAL64 [8], WORD [4], size_t [4*], void [ mapped to C type "void"; has no size ]
      "*" indicates that in XDS-C, these types are mapped to respective C types
    • DML possible via pre-built DLLs
    • provides some metaprogramming
    • free time-limited trial version and restricted demos are available
  4. OM2: 32 bit Oberon-2 and Modula-2 Compiler for PC/DOS.
    • 4a) is no longer available (this product was retired in 22-Jun-1999)
    • name and [size in bytes] of additional data types in module SYSTEM: INT8 [1], INT16 [2], INT32 [4], CARD8 [1], CARD16 [2], CARD32 [4]
    • command line compiler; also runs in a DOS box under WNT, W95/98, W3.1 and OS/2
    • the free restricted evaluation kit is no longer available
  5. COJ: Canterbury Oberon-2 for Java
    • 5a) For OS/2 or Win-95/98/NT: MED recommended. For MacOS: Works fine under CodeWarrior (see installation notes). Other platforms: no IDEs yet tested.
    • 5b) Some Oakwood Guidelines compatible modules: SYSTEM, In, Out, Files, Strings, Math, and MathL. Also, any foreign Java class, e.g., JDK 1.02, JDK 1.1, JDK 1.2, Swing, and JFC etc., can be accessed via a direct import mechanism.
    • 5c) RTD not included, but any Java-debugger can be used.
      Question to the implementor: does the Java-debugger allow Oberon-2 source level debugging?
    • 5d) Under the provision that the Java hosting operating system used is year 2000 compliancy
    • name of additional pervasive data types in module SYSTEM: none
    • additional non-standard procedures for exception handling:
      • SYSTEM.THROW(Te) throw an error or exception of type Te. Te is the (possibly extended) Java type java.lang.Throwable.
      • SYSTEM.TRY start a exception-guarded statement sequence.
      • SYSTEM.CATCH(Te) catch an exception of type Te. Te is the (possibly extended) Java type java.lang.Throwable.
      • SYSTEM.FINALLY start of final statement sequence, always called at the end of SYSTEM.TRY statement.
      • SYSTEM.ENDTRY end of SYSTEM.TRY statement.
    • free time-limited restricted trial version available for several platforms
    • source code for Oakwood Guidelines compatible modules included
    • more features
  6. JOB Compiler Oberon-2 to JVM byte code compiler.
    • 6a) Oakwood Guidelines compatible modules : In, Out, Files, Strings, Math, MathL, XYplane; 46 definitions modules for Java API (javalang, javaawt, javaapplet, etc.)
    • 6b) Any Java-debugger can be used.
    • 6c) Under the provision that the Java hosting operating system used is year 2000 compliancy.
    • 6d) The current beta version is free.
  7. OOC Compiler
    I'd appreciate if a responsible for this product would provide further details and links.
    • 7a) GC is available as a separate [free] package
    • additional pervasive data types:
      • HUGEINT, integer of size=8 (but, as I checked the source code in summer 1999 and MAX(HUGEINT) was set to MAX(LONGINT); OOC is a 32 bit compiler; there are no HUGEINT literals or HUGEINT constant expressions.
      • LONGCHAR, character of size=2

      Remarks on OOC's 64 bit HUGEINT type extension and OOC's claim that OOC would be a 64 bit compiler on a 64 bit machine (please correct me if I'm wrong; for a specification of terms see What is a 64 bit compiler?)
      I checked the latest source of OOC in Aug-1999. OOC is a 32 bit compiler, even when run on a 64 bit machine. The scanner can't parse 64 bit integer literals. MAX/MIN (HUGEINT) is set to MAX/MIN (LONGINT) in the ANSI C back-end. (In Aug-1999, OOC did not have another back-end.)
      The library is 32 bit only -- what concerns integer-to-string conversion and vice versa. OOC uses the library for string-to-number conversion in its scanner. If one wanted to migrate the OOC library to 64 bit, all formal parameters of type longint of all exported procedures must be converted to hugeint, and the conversion routines must be adapted accordingly.
      OOC does not have a built-in number conversion from real to hugeint. The result type of ENTIER() is always LONGINT.
      The OOC compiler internally uses only LONGINT, which doesn't allow to store or evaluate 64 bit constant integer values or expressions.
      The OOC compiler has 32 bit restrictions all over the place (size of data structures, maximal index in array declaration, maximal index in dynamic arrays, size of local and global variables, size in SYSTEM.COPY, and SYSTEM.MOVE).
      To overcome these 32 bit restrictions, the OOC compiler would have to use HUGEINT instead of LONGINT in most places. But such a compiler would then no longer compile on 32 bit machines. This proves that OOC's 64 bit integer extension results in 32 bit incompatibility. OOC's HUGEINT type extension does not allow seamless migration from 32 bit to 64 bit.
      If OOC took the same approach as A2O/AOS, i.e. basically (1) eliminating the pervasive type HUGEINT, (2) putting non-abstract integer types into module SYSTEM (SIGNED_8, 16, 32, 64), and (3) defining the abstract integer type LONGINT according to the word/address size of the underlying processor, OOC's source could -- with reasonable effort -- be made 64 bit upward compatible. This approach requires no language changes and thus guarantees compatibility with existing source code and programs developed with other 64 bit Oberon-2 compilers (although currently, there is only one such compiler implementation, namely A2O/AOS).

  8. CP/BBox Compiler
    Component Pascal is a derivate of Oberon-2 developed by Oberon Microsystems.
    I'd appreciate if a responsible for this product would provide further details and links.
    • 8a) free only for private, non-commercial use.
    • 8b) only some modules, e.g. Forms
    • can't index an array with LONGINT
    • does not have LONGREAL as pervasive type; REAL has size 8 and SHORTREAL has size 4.
    • SYSTEM.BYTE is a signed integer
    • additional pervasive data type: SHORTCHAR, character of size=1
  9. OBC: The Oxford Oberon-2 Compiler. OBS is a free compiler available with source code written in CAML and the run-time system written in C. Binary versions are available on 386 PC's under Linux, and on 386 PC's under DOS (using DJGPP). The compiler generates code for an abstract [hypothetical] machine, called "bytecode" (this is not the same as JVM byte-code). Separate OBC modules are linked to the main program. Programs are executed by an interpreter.

    • 9a)The library modules set, comprising the modules In, Out, Err, Math, MathL, Args, Random, XYplane, Conv, String, and Bit are basically compatible to the modules specified in [PIO], but a few things were added, and perhaps there are one or two things missing.
    • Differences between Oxford Oberon-2 and the Oberon-2 language definition of Appendix A in [PIO]:
      • The numeric types are restricted to INTEGER(32-bit integers), REAL(single precision floating point), and LONGREAL(double precision floating point). Thus the types SHORTINTand LONGINTare not implemented, and the built-in functions LONGand SHORTare available only for converting between REALand LONGREAL.
      • The built-in function ENTIERreturns INTEGER instead of LONGINT.
      • Within each module or procedure, it is not necessary to order the declarations so that (nested) procedure declarations follow all others. Instead, declarations of constants, types, variables and procedures may appear in any order.
      • The scope of a procedure includes the bodies of all procedures defined at the same nesting level, without the need for 'forward declarations'. In fact, such forward declarations are not permitted.
      • Open arrays are restricted to one free dimension. Thus the type ARRAY OF ARRAY OF INTEGERisnotallowed, but the type ARRAY OF ARRAY 10 OF INTEGER would be allowed, because the second dimension has a constant bound.
      • There is no garbage collector. Heap storage, once allocated, is never freed or re-used, except where the re-use is programmed explicitly

References

[PIO] M. Reiser and N. Wirth, Programming in Oberon: Steps beyond Pascal and Modula-2, Addison-Wesley, 1992.

Revision history

I'd like to thank everybody for their help to create and maintain this summary.

The Alignment Trap :: Navigator

[ The Alignment Trap Home | About The Alignment Trap | Oberon System and Compiler Implementations (OSCI) | Comparison of Oberon-2 with Modula-2 | From C/C++ to Oberon-2 | Oberon-2 Language Report | AlphaOberon-2 Compiler User's Guide | Download AlphaOberon for OpenVMS Alpha ]

modulAware.com home


Copyright (1999-2011) by modulAware.com
Last revised 01-Mar-2011

Disclaimer:
1) As the data shown in the above survey were kindly provided by the manufacturer of the products, modulAware.com can not be made liable for any typographical errors, omissions, inaccuracies, and incorrectness. Corrections are welcome. modulAware.com is not responsible for the content provided by following any links given.

2) The banner advertisement at the top of this page is dynamically inserted by the web-site hosting service; hence the banner image content and the URL it refers to is outside the responsibility of modulAware.com