Project Oberon 2013 on RISC-V | Hacker News Reader

Project Oberon 2013 on RISC-V

github.com

140 pointshomarp43 comments

Hi,

this port of Niklaus Wirth's Project Oberon (http://www.projectoberon.com) to RISC-V (rv32im) is the semester project of my student Rikke Solbjørg at the department of computer science at NTNU in Trondheim/Norway.

The system currently runs in a version of Peter de Wachter's emulator modified to use a RISC-V CPU emulation instead of Wirth's RISC5 (now isn't that confusing? ;-)).

Rikke's announcement on the Oberon mailing list: http://lists.inf.ethz.ch/pipermail/oberon/2020/015269.html

To answer the obvious question right away: yes, we are working on a FPGA implementation :-). Happy to answer your other questions...

Just to congratulate everyone involved.

Any thoughts about pursuing similar endeavours with System 3?

System 3 is closer to modern systems in L&F, which could make some students feel more inspired to delve into Oberon based platforms.

Just as an idea for other upcoming projects, I guess.

We are currently discussing a number of ideas for a followup project in addition to creating an FPGA version...

I'm currently digging through the 1992/2005 edition of the Project Oberon book (for the National Semiconductor 32k-based Ceres workstations from ETHZ - https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf). The Ceres Oberon version had a number of additional features, e.g. it could use the MMU for memory protection, which the RISC5 version doesn't support.

How much memory does it require to run?

The original Wirth RISC5 version runs in 1 MB RAM on an ancient Xilinx FPGA board. The RISC-V binaries are a bit larger, but still runs in 1 MB (but more is possible). A bit too large for typical block RAM sizes of affordable FPGAs, unfortunately.

Some details on the port and the binary size differences can be found in the project report: https://github.com/solbjorg/oberon-riscv/blob/master/report....

"block ram" (like iCE40's sysMEM) is usually very fast, fancy and dual port, which is why there's so little of it, and is typically spread across the die for reduced latency purposes.

From a CPU-in-FPGA perspective, it could be used for e.g. L1 cache. Actual RAM can be slower and external to the FPGA chip.

The ULX3S (which can support the minimig Amiga implementation) and the DE10-Nano (miSTer's base board) would make overkill targets for this.

Of course, external RAM is an option. However, using external SDRAM increases the complexity of the hardware significantly, which takes away a bit of the elegance and simplicity of Wirth's original RISC5 FPGA system. Wirth's system used a Xilinx Spartan 3 board with 1 MB of 32 bit wide fast asynchronous SRAM (https://multicores.org/blog/small-is-beautiful.html).

Unfortunately, FPGA boards with 32 bit wide SRAM are really hard to find nowadays, especially those supported by SymbiFlow...

Definitely. SRAM is pure joy to use, but less and less common in FPGA devboards by the day.

We (CFB Software) recently managed to squeeze the full Project Oberon into 512 KB of BRAM on Digilent's Arty7-100T and NexysA7-100T boards. It is sufficient to recompile the entire system on itself.

I'd love to see a text-only version. That would be fun to develop against and almost any FPGA should be able to run it. Might evolve into an interesting embedded platform over time.

Astrobe provides Oberon systems for embedded applications, there is currently a version using Wirth's RISC5 running on 7-series Xilinx FPGAs - https://www.astrobe.com/RISC5/

They also have a version for ARM Cortex-M controllers: https://www.astrobe.com/Oberon.htm

The "Project Norebo" bootstrap system that this is based on is such a text-only adaptation. It's used for building Oberon system images from a machine that isn't itself running Oberon. Norebo works by taking what is otherwise a full-fledged Oberon system, NOP-ing the hardware display routines and relevant GUI setup, and then it hooks all writes that are destined for Oberon.Log (the text object that appears in the top right viewer by default on a vanilla Oberon system). The build scripts run this system in a headless emulator, and the text written to that log gets dumped over a serial interface instead, which eventually appears in the terminal as stdout.

Here's a two minute video showing these build scripts running twice in a modified Norebo environment and producing identical disk images. The notable thing is that the first time it runs, it's actually running in a web browser―fully in a web browser, not shelling out to some cloud provider.

EDIT: Sorry about forgetting the video link. It's here: https://www.youtube.com/watch?v=TUpd70Mu0Ek

Hi, Michael.

I'm familiar with Oberon and have contributed to Peter De Wachter's Norebo bootstrapping scripts. I wrote a recent comment in another thread about the use of "applicative literature" in pedagogy. <https://news.ycombinator.com/item?id=25490826> Rikke's README for this project—and many other projects related to Oberon—end up describing processes in natural language, with steps to be performed manually, e.g. to change the bootloader. This is not special to Oberon, though. The gist of my argument is that pretty much every student and professor already has a suitable environment for handling process documents that could be adapted to be also executable by a machine. Do you have any thoughts about this? Do you have any experience trying to work with anything that follows Knuth's "literate programming" paradigm (including difficulties you've encountered)?

Anyway, nice work by you and your students. Wirth's RISC machine has a simplicity that others don't, which makes it good for teaching, but it makes some pragmatic choices that make it more realistic than similar attempts that result in toy computers that are a little too toy-like. It's work like this that makes for a decent transition after going from not knowing anything about a computer to hands-on understanding using a practical fantasy system like Wirth's to a full-on "industry-approved" instruction set RISC-V.

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).

It's great to see Oberon still being worked on! Slightly unrelated, but I was wondering if Composita was being used or looked at still (http://concurrency.ch/Content/publications/Blaeser_Component...)?

I know that it and A2 are more complex than Oberon, but a riscV version of those would be awesome, particularly the concept of managed memory without GC.

A2 gets updates every few months.

I am hoping to be able to work on a more “native” UX for it for MacOS rather than the xorg/X11 based one.

There’s ARM support already too but I don’t think M1 works in any sense yet, so I guess I’ll have to use Bonjour2 for now.

Fun stuff!

Hi everyone,

I've been working on this project for the last few months. I'm glad you find it interesting!

I won't reiterate what my advisor has already said, but like mentioned in the README of the linked repository, if you just want to try it, you can clone the emulator here, which includes a RISC-V image: https://github.com/solbjorg/oberon-riscv-emu

The port should also be quite easy to hack on, if you so wish. :) I'm happy to answer any questions as well.

Can anyone give a quick summary of what makes Oberan OS interesting? Is it an RTOS? A microkernerl? What's distinctive about it?

It is a complete computing system (meaning you can do actual useful work with it) that is deliberately designed to be simple enough that a single person can understand every bit of it--processor, compiler, operating system, and applications--in a reasonable amount of time.

Can you define 'complete'? Surely this doesnt mean including applications like 'word' or 'excel' or does it? Is a GUI part of the 'complete'? I really want to know what hides behind this term.

Project Oberon includes a GUI that in the Unix world would be described as using a tiling window manager. It doesn't include a word processor or a spreadsheet app - Oberon was created to build a workstation system, not an office machine - but a graphics editor is included. Other applications are available, of course, such as a tool for digital circuit design or an email tool.

But one of the most important use cases for Oberon is probably software development - so one of the most important tools that is included with the system is the compiler.

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/

What is interesting about Oberon is that it is a complete (i.e. OS + compiler + HW) usable system that can be understood in its entirety by a single human being within one lifetime.

As far as I know it's also the only system currently in existence that fullfills that promise.

CollapseOS is trying to meet that promise too. It’s interesting because it does unwittingly follow Wirth’s thinking. Collapse would be a consequence of allowing ourselves to not to understand our systems.

You could have put TempleOS into that bucket too, but unfortunately the author is no longer with us. RIP Terry :(

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..

And yet ETH has virtually abandoned Oberon. The younger people associated with the project had to move elsewhere to continue, it seems. That’s a shame.

It is hard to keep the ball rolling when the project drivers are no longer around.

I expect the same to happen to Linux when those of us that grew up with it, Linus and his gang are all gone.

Whoever comes next will just drive it into something else.

You already see this with the uprising of MIT licensed POSIX clones for IoT devices, or most userspace innovations being driven by a single company.

Regarding ETHZ, at least Active Oberon seems to still be being worked on

https://lists.inf.ethz.ch/pipermail/oberon/2019/013611.html

You are talking about likes of Zephyr or NuttX?

Among others, those aren't the only contenders.

Alan Kay made a really noble and modern effort at VPRI, but his group detonated and disintegrated for reasons never made clear, leaving the project unfinished with no community follow up.

Besides what others have written.

It is a complete single user graphical workstation OS, written in a GC enabled systems programming language.

Niklaus Wirth got his inspiration out of Mesa/Cedar during his second sabbatical at Xerox PARC (during his first one he ended up creating Modula-2 inspired by Mesa).

You can see what Mesa/Cedar was capable of by checking this videos,

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

The original Oberon system was a simplified version of it in more affordable hardware, then from its roots, a series of other variants were born, Oberon-2, Active Oberon, V4, System 3, Component Pascal, Zonnon, are the most well known. Eventually Niklaus Wirth decided to go back and see how much he could remove from original Oberon and still have it be a systems programming language with GC, thus Oberon-07 was born, with a couple of revisions, the latest one from 2016.

Going back to the original one, this is what you got in the package:

- A full stack single user graphical workstation, in a GC enabled systems programming language

- The only kind of application are modules, loaded dynamically

- Applications are just modules that register themselves into the system to be available on the REPL or in menus when loaded, e.g. Module.Command will load Module and call the procedure named Command, which can then be fed data from the REPL, mouse selection or selected application window

- This brings dynamism similar to Smalltalk and Lisp machines where you get access to whole OS and each application is extensible

At a given point during the 90's the ETHZ IT department had plenty of people using Oberon based workstations.

For a couple of screenshots about Oberon System 3 and Active Oberon, with links about Xerox PARC related stuff have a look at https://www.progtools.org/article.php?name=oberon&section=co...

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.

For that I would actually advise something like Smalltalk.

https://pharo.org/

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

Not unequaled, it has a certain Amiga OS feel actually.

System 3

https://www.progtools.org/compilers/tutorials/oberon/oberon-...

Amiga Workbench 3.0

https://www.gregdonner.org/workbench/wb_30.html

However I do get your point.

I never got to use Amiga Workbench 3.0. The thing about OberonOS with Gadgets was that it provided a very clean and simple way to embed widgets in documents and have them work across the whole system (kind of like CORBA.) See the "Inspector" panel in the Oberon screenshot? That's editing some widget live.

https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

I know, I used Native Oberon back in the day. :)

Yes, those ideas are similar to ToonTalk (on Sun), CORBA, COM/DCOM/OLE, DBus,... just done in a more easier and approachable way.

I also happened to be the only PC dude among a circle of Amiga owning friends, so I know it relativity well.

Amiga had lots of good stuff, including a similar feature, and the ability to script whole applications via ARexx.

I advise a reading of https://datagubbe.se/ltmag/

Ah, a man of culture. I should have guessed. :)

I got to see an Amiga in action when I visited a friend who lived in England. It was soooooo awesome.

(I had to cut my teeth on an IBM PCjr.)

There were a bunch of insightful comments when the wikipedia articles was discussed here last year¹. Some about Oberon in particular, and some about the surrounding ecosystem and history.

¹ https://news.ycombinator.com/item?id=21383016

Oberon: The overlooked Jewel has been posted here a few times: http://people.cs.ksu.edu/~danielwang/Investigation/System_Se...

This is the best single-page intro I've seen:

http://ignorethecode.net/blog/2009/04/22/oberon/

https://en.wikipedia.org/wiki/Oberon_(programming_language)

Reply on news.ycombinator.com