[Oberon] Project Oberon: New Edition

[Claudio Nieder]

Hi,

> would be more of a challenge to rewrite the lowlevel part of the source 
> in (sorry) gcc or Python so that the new Oberon could be ported to 
> proven hardware.

As I am not active in Oberon anymore I should keep my mouth shot, but this idea sounds so wrong to me, that I can't keep quite. I see Oberon as a way to build a whole system - OS, Compiler, User Interface - in a rather simple manner and formulated in a single programming language, so that it is possible that a single person can understand it as a whole. To mate this with a monster of several millions of lines of codes written in a foreign programming language seems just plain wrong.

I think that adapting the Oberon System to a new processor architecture isn't very difficult as proven by Oberon V4 which was available for several OS (Windows, Solaris, AmigaOS, ...) and processors (x86, Sparc, PA-RISC, 68k, ...). What was IMHO done wrongly at that time is, that the different implementations where not part of a coherent code base, but handled more like independent forks. So not only was e.g. Solaris/Sparc Oberon ported to HP-UX/PA_RISC but also modules of the system independent part improved without backporting the improvements to Solaris/Sparc leading to unnecessary fragmentation. More on this later on.

Furthermore once a port is made, the amount of maintenance is very low given the basic assumption of Oberon being a simple system. With preferring a simple and readable compiler over one that strives for maximum performance of generated code at a cost of being a monster like gcc one would not have to follow processor evolutions as one would never e.g. try to optimise code by supporting the latest vector instructions etc. E.g. most probably the last change to be followed on the intel processor family would have been the inclusion of x86-64 about a decade ago, and since then the compiler would have remained untouched. 

> A good start would be to port Native Oberon to gcc but the sources of NO 
> are very hard to get.

One remark to your mention of Native Oberon. If by that you mean really native i.e. running on the bare hardware, then you run into a challenge which is much bigger than adapting to different processor architectures. After all there are just a handful or at most a dozen architectures which are really interesting. Running natively means you have also to support gazillions of different peripherals. Not only the numbers work against you, but also change is much more common in this area then with processor architectures. My gut feeling is, that the developer base in the Oberon community is too small to keep a native system up to date for any useful definition of up-to-date. I remember having had a look at NO at the time it was most actively developed and even though I had a fairly standard, i.e. not using very exotic chip sets, laptop computer I could not make NO run on it in any usable way. I will come back to this too.

Some 15 years ago after working on Oberon4Amiga and seeing the fragmentation issue, once I found some spare time I decided to unify back the different V4 ports. Unfortunately my period of spare time ended too soon, I was not able to find enough other people who would share my idea both because I am not the born leader but also because a lot of people interested in Oberon preferred System 3 over V4, which had lead to ever more variants of Oberon. Nowadays we have also AOS. Each of these has its followers because the needs of each of them seems to be different. Some people on this list care mostly about the TUI and are happy having that with any other kind of OS running beneath of it. Others might even hate the TUI because the mouse-interclicks cannot be translated to touch screens but on the other hand like to have a nice programming language and a small footprint, understandable OS they can use on limited resources devices. In this context going native might even make sense, when the target platform is small, strictly defined with only few peripherals that are expected not to change significantly over a large period of time.

In addition to fragmentation in the code there is also fragmentation in the objectives and desires of the Oberon-lovers and this is in my opinion the main reason why you don't see Oberon brought to more hardware, not enough resources devoted to do it. I don't see how mating Oberon with gcc could change that a single bit.

If you want to go forward and get Oberon running on a particular platform you care for, than I would suggest to proceed like this:

- Identify whether you want to have it running on bare metal or with some other helping OS beneath it.
- Look around for Oberon sources which are as near as possible to what you need to support your target platform.
- Analyse what the gap is between the sources you find and what you need to have to support your target platform.
- Estimate whether you would be able to do the work by yourself. If this is not possible see if you can find enough other people also interested in seeing Oberon happen on that particular platform. When doing your estimates take into account maintenance. How much is the platform expected to change over time and what resources do you need to keep track with these changes.
- Once you find you got enough resources committed to it, do it and make the (Oberon) world know about it.

From my past experience let me express one wish if you actually do such a project: Make sure you integrate somehow your new work with the source you based from to avoid increasing the fragmentation we already have. E.g. if you base on Oberon V4 and take a source from http://sourceforge.net/p/oberon/oberonv4/ci/master/tree/ then arrange so that your additions get back into this repository instead of being an independent fork on another repository.

claudio
-- 
Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch