[Oberon] Porting S3 / V4 Oberon (was: File transfer)

Chris Burrows chris at cfbsoftware.com
Sun Jan 3 00:42:17 CET 2021

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Skulski, Wojciech
> Sent: Sunday, 3 January 2021 6:50 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] [EXT] Re: File transfer;
> > Inheritance is a common feature of Oberon types, also Oberon-07
> offers it.
> Instance-based, yes. Type-bound, no.
> Andreas already implemented the latter in his compiler. So it has
> been fortunately reintroduced.
> Remaining "embellishments" are multiple RETURN, LOOP-EXIT, etc. NW
> wrote that there were very few instances of the LOOP-EXIT in the
> entire Oberon System. So it is not very critical to get it back.

Wirth is talking about Project Oberon. You are thinking ETH Oberon / Linz
Oberon aren't you? There are approximately 350 EXIT's in both ETH Oberon and
Linz Oberon.

> Concerning multiple RETURN, I just do not buy the argument that its
> elimination helps with code quality. 

These are more difficult to identify as there are somewhere between 1000 and
1500 RETURNs in the ETH / Linz code. It would take significant further
analysis to identify which are candidates for elimination.

Also, don't forget there are a number of more subtle differences between
Oberon 1990 (which Oberon-2 was based on)and Oberon-07 which would cause you
more headaches e.g. the INTEGER / REAL compatibility rules, the availability
of certain standard procedures etc. No fatal issues, just death by a
thousand cuts.

It is clear that you prefer the Oberon-2 language to Oberon-07. I'm not
going to attempt to change your preferences and beliefs any more than I
would if you stated that you enjoy eating anchovies more than eating
chocolate. I enjoy both, but not at the same time, in case you are wondering

If, for whatever reason, you want to implement ETH Oberon OS / Linz Oberon
OS on a hardware platform which does not already support it, the most
time-efficient way I see of porting it is to first of all implement a
compiler for that platform that is 100% compatible with Oberon-2. If RISC5
is the target, Andreas's work would be a good starting point, rather than
attempting to port the existing S3 / V4 Oberon-2 compilers. I believe this
would be significantly less effort than attempting to change either system
to be compatible with Oberon-07. The choices that you have to acquire such a
compiler are, as far as I can see:

1. Create it yourself
2. Pay for the time it takes for somebody else to create it for you
3. Find somebody who shares your dreams and is capable of creating it for

My guess is that 1) has the most probability of happening but you may have
other ideas.

Chris Burrows
CFB Software

More information about the Oberon mailing list