Ublantis' 1st Independent Oberon & Modula-2 Technical Publication
Nr. 95, Nov-2015
This issue contains the source of Alpha Oberon System (AOS)**** boot loader for HP Alpha OpenVMS together with the source of its imported modules.
AOS is a (64 bit) port of ETH Zurich's (32 bit) Oberon System V4 to the HP Alpha OpenVMS 64 bit operating system* with X Windows. The 32 bit port was completed in 1995, the 64 bit version in 1997.
AOS includes Regis Crelier's object model and Josef Templ's metaprogramming and —based on the latter— Markus Hof's symbolic run-time debugger.
32 bit Ports of Oberon System for other operating systems like Linux and Windows exist; their boot loader is written in C.
In contrast, AOS is fully 64 bit (memory addressing and LONGINT, see Oberon-2 from 32 bit to 64 bit — without any programming language change) and as of writing this article (in Nov-2015) AOS is still the only port with the boot loader itself written in Oberon.
The boot loader compiles with ModulAware's Alpha Oberon-2 native-code compiler (A2O). The port is described in the article Porting the Oberon System to AlphaAXP. A more detailed description is contained in 64-Bit-Portierung des Alpha-Oberon-Systems und des Oberon-2-Compilers (PDF), written in German.
Oberon's X Window interface module is not needed by the boot loader but it's OpenVMS implementation module X11 is nevertheless shown below together with the foreign definition X11$ it imports.
I'd like to thank the ETH Zurich and University Linz Oberon teams for their work as well as Hartmut Goebel, Peter Pirkelbauer, and Don P. Ward who contributed to the AOS port at ModulAware.
*) At the time, Alpha OpenVMS operating system was already fully 64 bit — and its system services were upward compatible from 32 bit (VAX/OpenVMS)***, apart from a very few restrictions, notably in file handles, exception handling, and it's layered product X Windows**.
Module Unix (see below) implements OpenVMS' file access interfacing. (We stuck with the module name Unix of the Oberon System's Linux port in order to change the original sources as less as possible.) In module Unix, procedure IsInP2Space is called in Unix.Chdir and Unix.Getwd to detect and buffer the data where necessary.
**) X Windows data structures use SIGNED_32 as address type. Thus the data it operates on must be located in the 32 bit addressing space. So most procedures in module X11 need to check if parameters are in Unix.IsInP2Space and buffer them when required. (Note the type declaration "LONGINT = SYSTEM.SIGNED_32;" in the head of X11 to fit X Windows 32 bit addressing restriction.)
***) The operating system, run-time library, and so-called object-time system interface definitions were upward compatible thanks to the default ('archaic') by-reference parameter passing mechanism of the most popular programming languages in the 1970s when VMS was developed for the DEC VAX, e.g., Fortran. See explanation in section "Assignment compatibility of pointer types" in "MaX V5 - 64 bit Modula-2 for OpenVMS Alpha — Implementation Notes (In C the default is by-value! Hence the address space restriction of X Windows (X11) which is written in C.)
****) Note, there is another acronym AOS in the Oberon scene which
Jurg Gutknecht from ETH Zurich uses for
Active Oberon System.
The confusion is not our fault, since we already used AOS for Alpha Oberon System
about 10 years before.
Gutknecht's AOS is a fork of his Zonnon... and is much different from Oberon[-1], Oberon-2, and Oberon-07. As of writing this, ETH Zurich's documentation page has a dead link to the Active Oberon System language report***** — same for its wikipedia entry.
If you are now confused by so many Oberon language versions, remain assured that this is what's called progress.
However N. Wirth's Oberon-07 (he derived in 2007
from Oberon[-1] and revised in 2013 and 2015 — the report has only 17 pages!)
is here to stay —and if I were a prophet,
I'd say— for more than 100 years. ;)
An ultimate [32 Bit] Oberon Station — a palm rest single board computer was announced in Oct-2015. It's open source (Oberon-07 and VHDL for it's Xilinx Spartan-3AN FPGA) and quote, "[it] boots [the] Oberon [GUI operating system] in about 1 second from the [micro]SD card."
*****) I found a copy here: Active Oberon Language Report by Patrik Reali, Oct-27, 2004.
A "$" in the filename of a module indicates that it is a 'foreign' module (outside Oberon System's name space) where the exported items are not prefixed with the module name and a ".". Such modules consist of definitions (data structure and procedure declarations) only and serve as interface to operating system services and run-time library procedures. For more details see the A2O V3 User's Guide".
(Last revised 01-Nov-2015)
Copyright © (2002-2017) by modulAware.com