Rediscovering Project Oberon

Way back in the early 1990s, when I was browsing a campus bookstore for the first time in my life, I remember coming across a remarkable book called “Project Oberon – The Design of an Operating System and Compiler” by Niklaus Wirth and Jürg Gutknecht. Just from a little browsing it became clear to me, that this was a true gem among computer textbooks. This book described the design and implementation of an entire operating system, including its implementation programming language, drivers, windowing system, everything!

The only comparable book that I can think of is Andrew S. Tanenbaum’s “Operating Systems: Design and Implementation”, which describes MINIX, another minimalist operating system for educational purposes. The UNIX-like MINIX 1.0 is probably most famous for having served as an inspiration and development platform for Linus Torvalds, while he began working on Linux. MINIX also led to a number of later variants, of which the latest, MINIX 3.0, is being marketed as a full-featured operating system.

But back to my story about Project Oberon… Unfortunately, I did not buy that book when I first saw it. Throughout the following two decades my primary interest wandered away from computer science, and even though I occasionally saw an Oberon related article here or there, I mostly forgot about it. This changed recently, when I stumbled over a free online edition of that very same book that I had first seen so many years ago. While I do not intend to design my own operating system or even just get deeper involved in operating system design in general, the introduction of this online book nevertheless proved to be a very interesting read.

The original Oberon system was designed to prove that operating systems could be made much simpler than its typical contemporaries, while still offering all the features necessary to power a personal workstation. Compatibility with other systems was not a requirement, so its inventors were free to experiment with novel concepts. In fact, they originally did not even stick to some standard hardware, but targeted their in-house designed Ceres workstations instead. Only later on, Oberon was ported to run on most major hardware platforms.

Oberon’s original user interface was a tiled window manager. Objects shown in any window, be they text or graphics, can be clicked, edited, and executed as commands. Under the hood, Oberon does not subdivide applications into distinct programs, but rather into different objects belonging to different modules. If I understand things correctly, there is not much protection of these objects from each other. Although the tasking model used is cooperative, not preemptive. This requires application code to be well behaved, at least to the point where it cannot easily crash the system.

Reliable operation of the Oberon system requires that only “safe” application code would be executed. To ensure this, all programs – pardon, modules – to be executed on the Oberon system, should be written in the Oberon programming language. This language, which was developed in parallel to the Oberon system, was specifically designed to be small and “safe”. It achieves the latter through strong, static type checking, and such features as array bounds checking and garbage collection.

Developing a system language alongside an operating system seems to needlessly complicate the problem, but it is not an all that unusual approach. After all, this same approach was applied earlier during the development of the UNIX operating system, leading to the extremely successful C programming language. What’s special about Oberon is that the language is required (or at least very strongly encouraged) for any software to be developed for the Oberon system.

The Oberon language is a classic “Wirth Language”, with strong similarities to its predecessor Modula-2, which again is quite similar to Pascal. There exist some Oberon compilers for other operating systems, which led to the Oberon language being somewhat more successful than the Oberon system.

The original Oberon compiler, described in chapter 12 of Project Oberon, compiled directly to machine code for the NS-32000 processor architecture, which was used in the Ceres workstations. Although the NS-32000 is a CISC processor, it has a relatively regular design, making code generation feasible within the scope of the project, but not simple.

In the newer book “Compiler Construction”, also available in a free online edition, Wirth specified an even smaller subset of the Oberon language, called Oberon-0, which only offers 32-bit integers and Booleans as native types, but otherwise includes many features of the full Oberon language, including records, arrays, and procedures. The Oberon-0 compiler in Compiler Construction targets a virtual RISC machine, which is much simpler than the NS-32000 processor architecture. The complete VM reference interpreter consists of only two pages of Oberon code. The complete code for the Oberon-0 compiler fits on 19 pages.

I do not think that the Oberon language ever stood a chance to become a mainstream programming language (otherwise its predecessor, Modula-2 would have already done so), nor that it was ever intended for that purpose. After two decades of existence, relatively few people seem to have ever heard of it. However, for those who are interested in learning about compiler construction (including their actual programming, not just their abstract design), there are few languages with such well-documented reference implementations as Oberon. Especially the compiler for the stripped down variant Oberon-0 is actually quite easy to understand.

While setting up a full Oberon system to play around with does not appear very encouraging, I am seriously considering some experiments with the Oberon-0 compiler. Maybe I could port that compiler to a language that I am more used to? Or, maybe I could even try to come up with my own language variation? (Just yet another useless toy language… but why not?) Or I could try to target a different architecture? Will see whether I can free up a little time over the holidays to play around with those ideas… If not, I fear that I might completely forget about Oberon again – and that would be a shame.

This entry was posted in ITE 221. Bookmark the permalink.

10 Responses to Rediscovering Project Oberon

  1. Thomas says:

    heh, how funny! I’m just spending my time in implementing the Oberon-0 compiler using (Free)Pascal. So, you are not the only one who is playing with Oberon or should I say playing with N.Wirths books.
    As I currently try to implement an ELAN-Compiler, I found out that the Oberon language has much features which are similar in ELAN. So I decided to implement the Oberon-0 compiler which than maybe used as a base for the ELAN compiler…

    Happy oberoning!


    • Ah PASCAL… haven’t used that language in a long time. Its similarity to Oberon should make re-implementing Wirth’s Oberon-0 compiler relatively easy (I think). I haven’t gotten around to work on my own re-implementation yet, and probably won’t do so for quite a while (ever?). In the meantime, let me know, how your effort goes!

      I had never heard of ELAN before reading your comment. It appears to have played an important role in German education for a short time. Or at least it was planned to play such an important role – the one eventually taken over by Turbo-Pascal instead. This makes me wonder what’s used in German high schools today… Java, or something a little more interesting?

  2. Bernhard says:

    truly, Project Oberon is a gem and the current version of the standalone operating system is a very interesting attempt to current topics like multiprocessing and user interfacing. Despite a lack of documentation as thorough as it was in Project Oberon, there is a tiny community at with basic documentation, a forum, and some people to help out …

  3. AP says:

    Reading this, my hand wanders over my bookshelf over to my well-worn copy of this book which I purchased in 1992 while a CS student et ETH. I didn’t realize that people are still talking about Oberon two decades later, but apparently it still is the case. In any case, going into industry after having studied CS at ETH was a real shock for me, to say the least. Gone was the culture of elegant design, and the days where one could do a project porting a compiler to yet another processor in a matter of weeks (!).

  4. Several years ago after experimenting with extending the Oberon-0 compiler and then being inspired by meeting Prof Wirth at an Oberon Day in Zurich it occurred to me that the 2007 revision of the Oberon language was a perfect fit for microcontroller applications using the 32-bit ARM devices that had recently become generally available. That was how Astrobe started …

  5. ron says:

    Did a lot of time in the “BEGIN … END” world, then did a little Modula, and ended up C/C++ like everybody else. Looked at Oberon twenty years ago, but didn’t have time for much investigation.

    Now, I’m having another (much belated) look. Wish I had that book by Wirth. It’s $135 on Amazon now, even with the age attached! Saw the link to the pdf, but was unsure of copyright, so I didn’t download it.

    I think there’s a cult following around all of these small kernel, obscure, operating systems because they are so easy to work on. Compared to Linux, they’re unfettered and clean. Important stuff is not obscured by less important baggage, etc. So I find myself looking at projects like Haiku, Minix, and yes … Oberon … twenty years later. Particularly, I’m interested in an ARM port, since everything’s going that way. I understand that NW is working on such a thing (albeit in a very small form factor) now, 15 years into retirement. Now dreaming … how about Oberon/A2 on a fancy new Tablet computer? -)

    • Ron, thanks for commenting on this old article! It’s interesting to see that people are still finding and reading this material, even though it is posted on a nowadays mostly dead blog. This reminds me that I should pay more attention to it, and perhaps even “reanimate” it with some new content…

      I haven’t looked much into Oberon/A2 since writing this (life, once again, got in the way…), but I agree that seeing this implemented to run on a modern tablet would be pretty cool!

      Regarding the two links: They lead to PDFs published on the author’s Web page. I did not find any licensing terms, just the author’s standard copyright notice. Both PDFs are slightly revised editions of the original books. I believe that reading these documents online should be okay (why else post them?), but this may not hold for saving downloaded copies. To know for certain, of course you would need to track down and ask the author himself.

  6. ron says:

    BTW: Nice article. You should try A2. I’ve been running it for a few days, although the bimbrowser is a little primitive, it’s been fun. I put it on some clearly dated hardware (1999) – and it’s fine. (You know, $35 ebay bargain machines 🙂 )

  7. ron says:

    Correction: I should say “RISC” relative to NW’s project.

    • Well, the ARM instruction set (at least in its original form) is about as RISC as it gets. I’m no expert at this, but I wouldn’t be surprised, if supporting it was easier than x86. Speaking of ARM, RISC, and computing history: Does anyone still remember the 1980s advertisements for the Acorn Archimedes? In German computing magazines that first ARM based computer was commonly introduced with: “RISC ist kein Risiko mehr!” meaning “RISC is no risk anymore!” Interesting, how ARM and Oberon both date back to the same era…

Comments are closed.