Installing OBC release 3.3

This page contains the materials and instructions you need to install release 3.3 of the Oxford Oberon-2 Compiler and associated programs on your own computer.

• Instructions for using the compiler are given in the user manual, which consists mainly of sections extracted from the lab manual for the Imperative Programming course.

• There is also a page with a general description of the compiler and associated tools, including licencing information and acknowledgements.

Sadly, I no longer have time to build binaries for Windows or Mac OS, for reasons I explain below.

Changes

Release 3.3, compared with release 3.1:

• adds support (with --enable-segmem) for a software virtual addressing scheme, making it possible to build a (slightly slow) bytecode interpreter that runs on 64-bit systems and uses only malloc for storage allocation. I haven't done any timing studies, but the scheme works well enough to be usable in the intended application.
• adds support for outputting a linked bytecode program as a set of array declarations in C syntax that can then be compiled and linked with the runtime system.
• changes to using an internal or external copy of lablgtk3 in place of lablgtk2 to implement the GUI for the debugger.
• changes to the interface of the procedures in the Out and Files modules for printing values of type REAL or LONGREAL. Previously these routines lacked the width argument that is standard in other Oberon implementations. It should be easy enough to add the parameter in client programs, but source modules OldOut and OldFiles are also provided that can be substituted by writing import Files := OldFiles, etc.

The first two of these changes were implemented as part of the project to make XML2PMX available as part of the TeX live distribution. XML2PMX is a program (implemented in Oberon) that is able to translate the file format output by musical score editors such as Sibelius so that they can be typeset using a system based on TeX. These changes were present in release 3.2, which was not widely distributed.

Compared with release 3.0, this new release extends JIT support to the amd64 architecture in addition to x86 and ARM, and adds the ability under Linux to use libffi in place of hand-written wrappers to call library functions. The 64-bit runtime executes the same bytecode program as the existing 32-bit runtime, and Oberon pointers and other addresses are represented in 32 bits; the storage manager is designed to allocate storage in the bottom 2GB of the address space to make this possible. Arithmetic on 64-bit integers is supported natively on amd64 instead of using library calls as on other architectures.

Compared with release 2, the release adds support for the Oberon-07 dialect of the language.

Fewer binaries

This release marks a point where I must cease to offer binaries for Windows or Mac OS. The same techniques used to create these binaries in the past should continue to work, and the adaptations of the JIT runtime to the different calling conventions of Windows will remain in place, but I simply don't have the time to continue building the GTK-based debugger application on these platforms. Binary packages for other platforms will remain: x86 and x86_64 and arm32 under Linux, with packages for Debian. For other machines, there is the option of building from source.

The change to using GTK3 and specifically gtksourceview3.0 will future-proof the software to a large extent, and I am intending for these to be just about the last public changes to OBC. I have learned a lot by writing and supporting it, and I hope taught a lot of young people through the medium of Oberon to think clearly about the design of programs. But things have moved on, and we no longer use Oberon for teaching in Oxford, preferring Scala for reasons that I have never fully understood. The time when I used the Keiko machine to teach our students about compilers is also past, and I have handed that pleasurable task over to others. If I do more work on implementations of Pascal-like languages, it will very likely to be in the area of embedded applications that run on ARM-based microcontrollers, where a language supporting concurrent processes along the lines of Modula(–1) has potential.

Source code and previous versions of the binary packages linked below are available from the releases page of the compiler's GitHub repository, where there is also an issue tracker. The current version is release 3.3.0.

Debian, Ubuntu and similar x86 or amd64 Linux systems

The compiler and associated software is packaged as a Debian archive that is installed under /usr. You need either the file obc_3.3.0_i386.deb (32 bits) or the file obc_3.3.0_amd64.deb (64 bits).

Copy it to your machine, then issue the command

$ sudo dpkg -i obc_3.3.0_i386.deb

(or the equivalent for amd64). Doing this may produce a message about unmet dependencies, and you can resolve them with the command

$ sudo apt-get -f install

(This package was built on an Debian Bullseye system, but should work on other Debian-based systems.)

Raspberry Pi under Raspbian

Installation on the Raspberry Pi (any model) is the same as on other Debian-based systems, except that you need the file obc_3.3.0_armhf.deb for the ARM architecture.

Copy the file to your machine, then issue the command

$ sudo dpkg -i obc_3.3.0_armhf.deb

If you get a message unmet dependencies, you can resolve them with the command

$ sudo apt-get -f install

This package was built under the Raspbian version that is based on Debian Bullseye.

Other Unix systems

The source code for the compiler and associated software is available on GitHub:

$ git clone https://github.com/Spivoxity/obc-3.git -b rel-3.3.0

After cloning the repository, you will find instructions for compiling and installing the compiler in the file README. Building the compiler requires OCaml and TCL, both of which come as standard packages on all good Unix distributions. Building the debugger (which is selected by giving the option --enable-debugger) requires development versions of the GTK libraries, including gtksourceview2.0.

Note: development of the compiler is managed with Mercurial rather than Git, and the GitHub URL above leads to a Git repository exported from Mercurial that is updated whenever there is a fresh release or bugfix. For more up-to-date information, you can use Mercurial to clone directly the repository on Mike's server:

$ hg clone https://spivey.oriel.ox.ac.uk/hg/obc-3 -u rel-3.3.0

The runtime system uses pointers are 32 bits wide, and has been made to work on amd64 by forcing memory to be allocated in the bottom 2GB of the address space. On x86, amd64 and ARM machines, the default runtime system includes a JIT translator; other architectures fall back to an interpreter for the bytecode, which is also used on all architectures to support profiling and debugging.

Version history

3.3.0

Initial release.

Known problems

• The JIT translator will not work under SELinux, because it depends on allocating memory that is both writable and executable. The source contains an option to avoid this, but it is untested.