Project Oberon 2013 on RISC-V

Oberon OS plus the "Gadgets" widget lib is unequaled in UI design in my opinion.

One interesting point about Modula and Oberon is that these systems were not only the topics of academic research (which are often quickly abandoned when the related project ends). Rather, the systems were used at ETH to educate generations of students over the period of more than a decade, running on custom-designed hardware from day one (the Ceres workstations).

We arguably spend too much time teaching our students how to work with complex commercial systems (or nowadays also complex open source systems such as Linux) and should try to rely more on self-developed software which can be understood, adapted and improved in a reasonable amount of time. I'm trying to revive some of that spirit in my courses and projects.

Maybe Oberon errs a bit too much on the side of simplicity. I don't think it's very problematic that the compiler doesn't implement sophisticated optimizations, but the OS part of Project Oberon does not implement memory protection (the older Ceres-based system did to some extent) or preemptive multitasking. This is appropriate considering the system's age and the constraints of the FPGA for the original RISC5 system, but due to this the OS part of Oberon is on a similar level as non-NT Windows and classic MacOS. Accordingly, it's not a very useful example design today IMHO. Other systems such as xv6 might be more appropriate here, but xv6 was never designed to be used as a desktop os for real-world use.

One problem that also affects other bare-metal systems such as Lukas Hartmann's Interim OS (http://interim-os.com) or my Smalltalk-80 port (https://multicores.org/blog/smalltalk-on-a-small-computer.ht...) for the Raspberry Pi, is handling the complexity of modern peripheral and communication protocols.

Some of the worst "offenders" here are USB and Bluetooth, both of which require driver and protocol stack code that often has more lines of code and is more complex than the rest of the system. Ethernet and TCP/IP might be a bit more manageable, Adam Dunkels' uIP/lwIP are a good example.

So, as always in system design, the art is to find the right tradeoffs. Exploring the design space here is interesting, especially within the constraints of a real-world ISA as a basis. And I think projects involving small operating systems and RISC V are lots of fun (I hope Rikke agrees ;-) - we also have students working on Plan9 and Inferno ports to RISC-V) in addition to be educationally worthwhile - IMHO an important point to keep students motivated.

I think we should probably all re-read Prof. Wirths "A Plea for Lean Software" (https://cr.yp.to/bib/1995/wirth.pdf) once in a while, but also consider how to apply the principles of this paper carefully instead of going for absolute minimalism. I hope that something along these lines will be a valuable learning outcome for the students working on my projects and attending my courses..

Literate programming could solve some of our everyday problems, such as discrepancies between documentation and implementation (in contrast with often hard to use automatically generated documentation e.g. using JavaDoc). I'm not sure why it never caught on - perhaps most programmers rather want to work on code and not on explaining it...

While not as elaborate as Knuth's WEB system, I liked the approach used by Douglas Comer in his Xinu OS books (my first OS textbook) very much. Comer's integration of explaining text sections and related code is not as tight as some of the commonly mentioned literate programming examples, but IMHO it still helps a lot to understand the system structure and the dependencies of the piece of code discusses with other parts of the system.

What is great about the Comer books is that - like Oberon - they also cover more than just the OS. In the original version of the Xinu book, there was an extensive explanation of the PDP11 the system was developed on, though not on a sufficient level of detail to actually build a PDP11. While Comer doesn't include a compiler or GUI in Xinu, he extends the system in another useful direction with Xinu-based Ethernet and TCP/IP support in a second volume. The Project Oberon book includes a short chapter on networking, but this is a point where the "not-invented-here" paradigm that helps to keep the Oberon system so simple and elegant seems to break down, as real-world interfacing is essential today. The difference in complexity between the homebrew approach and TCP/IP is easy to see, however. Networking is covered in a single chapter (IIRC) in the Project Oberon book, whereas it took Comer a whole book volume to describe his TCP/IP implementation (admittedly, also including the description of a number of network protocols on top of TCP/IP).

With a view to a portable environment, I was thinking earlier today that it would be nice to have a second, all-in-one application to use over different OS environments, to complement a modern browser. Something with a file explorer, editor, support for scripts -- and possibly extensions. It appears non-native Oberon could be a fit to that; the lack of an up-to-date browser would not be a weakness.

In addition to the OS itself, the Oberon book [1] includes network, file and print servers, a mail server, a text editor, and a graphics editor capable of drawing circuit schematics.

[1] https://people.inf.ethz.ch/wirth/ProjectOberon/