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@zel.org. 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

• V4: Oberon System V4, SSW, University of Linz, Austria
• S3: Oberon System 3, ETH-Zurich, Switzerland
• ISO M2: ISO Modula-2 library
• PIO: Programming in Oberon book [PIO]
• PROP: proprietory library
• IDE: specify if applicable
• DML: dynamic module loading on demand without linking
• Lib: separate module library compatible with V4, S3, ISO M2, PIO, or PROP?
• fgs: Fine grained symbol file, also called object model
• Ref: metaprogramming; V4 compatible (others, please specify)
• RTD: symbolic run-time debugger (V4); other please specify
• TVboR: trap viewer based on Ref, i.e., uses folds for structured types, or other post-mortem debugger
• GC: garbage collector; specify if it can't cope with open arrays containing pointers.
• Y2K: year 2000 compliant
• free: available for free or for small handling charge
• src: source code available
• am: actively maintained
• pv: procedure variable
• PTR: SYSTEM.PTR
• ADR(): result type of SYSTEM.ADR()

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

• created table entries for AOS, A2O, and XDS provided by in 09-Mar-1999.
• added OM2 in 03-Apr-1999.
• completed AOS, A2O, XDS, OM2, and added COJ in 09-Apr-1999.
• Sergey Z. Sverdlov c3c@uni-vologda.ac.ru added JOB in 11-Jul-1999.
• added OOC and CP data type sizes in 19-Jul-1999, but only partially, based on a posting in news:comp.lang.oberon from Ian Rae (mailto:ian.rae@REVERSETHIS.com.pronexus) because I've not got more information.
  (Several months ago, I asked the author/company responsible for OOC/CP compilers be email to submit their data, but still got no reply. But I can wait...)
• added Oxford Oberon-2 in 22-Oct-1999 with the help of Mike Spivey mike@comlab.ox.ac.uk and the remarks on how OOC could overcome its 32 bit restrictions.
• corrected CP entry. Thanks bernhard@imp.med.uni-muenchen.de

.zel.org Website Navigator

[ .zel.org Home | 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 Modula-2 and Oberon-2 compiler web-site