January 2021 - Oberon - mailman3.inf.ethz.ch

Porting S3 / V4 Oberon
by Andreas Pirklbauer 04 Jan '21

04 Jan '21

> >Add the small number of “Original Oberon-2” features such as LOOP, EXIT > >and RETURN to the compiler just to *initially* speed up the porting effort of > >V4. But *eventually* eliminate those constructs *on* the then-ported system. > >The advantage would be that one would not need to also deal with porting > >complex, nested LOOP statements initially, thereby reducing risk of errors.. > > Sounds like a plan. A dream would be to have a V4 successor named V6 > replacing V4 under Windows and Linux, and also running on the FPGA. An alternative approach would be to *first* rewrite V4 under V4 itself to "clean it up", as you had suggested in a previous message, i.e. first eliminate LOOP, EXIT and RETURN *under V4*, step by step, while keeping V4 running. Then compile for FPGA (either on V4 using a cross-compiler or on the FPGA itself). That way, one doesn’t need to amend the Oberon-07 compiler. PS: Personally, I would be more interested in V4 für RISC-V, where Extended Oberon also runs (but with no memory limitations).

2 1

Porting S3 / V4 Oberon
by Andreas Pirklbauer 04 Jan '21

04 Jan '21

> A small LOOP with a single EXIT is relatively painless to fix. It is when > you get nested LOOPs spanning many lines with multiple EXITs (and possibly > RETURNs) in each that life becomes interesting. > > This is where evolution kicks in. The lifetime of such code is limited by > the number of people who are able and prepared to maintain it. One possible approach could be: Add the small number of “Original Oberon-2” features such as LOOP, EXIT and RETURN to the compiler just to *initially* speed up the porting effort of V4. But *eventually* eliminate those constructs *on* the then-ported system. The advantage would be that one would not need to also deal with porting complex, nested LOOP statements initially, thereby reducing risk of errors..

2 1

[EXT] Porting S3 / V4 Oberon (was: File transfer)
by Andreas Pirklbauer 04 Jan '21

04 Jan '21

> >Understood. But is there, or will there be, a serious (!) effort to > > port Linz V4? > > I plan to give it a spin. There is one more potential participant. To repeat: Adding EXIT, LOOP and RETURN to the compiler is certainly doable, but the effort to port V4 would have to be real *and* the target system would have to be publicly available *and* already run the Oberon system (e.g., in the form of an emulator of a system with enough RAM)

2 1

Re: [Oberon] Porting S3 / V4 Oberon
by Chris Burrows 03 Jan '21

03 Jan '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > peter(a)easthope.ca > Sent: Monday, 4 January 2021 1:39 AM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Re (2): Porting S3 / V4 Oberon > > One practical question I can't suppress. Are the three, EXIT, LOOP > and RETURN advisable or required? In my very limited experience, > removing LOOP is relatively painless. What about tolerating RETURN > and EXIT but not LOOP? My knowledge is inadequate to judge the > tradeoff. > LOOP and EXIT in Oberon-2 go hand in hand. With care, you can use a multi-file find and replace tool to replace all "LOOP" statements in hundreds of source code files with "WHILE TRUE DO" in seconds. However, the EXIT statements are then orphaned because they are only legal within a LOOP statement. A small LOOP with a single EXIT is relatively painless to fix. It is when you get nested LOOPs spanning many lines with multiple EXITs (and possibly RETURNs) in each that life becomes interesting. This is where evolution kicks in. The lifetime of such code is limited by the number of people who are able and prepared to maintain it. Regards, Chris Burrows CFB Software https://www.astrobe.com

1 0

[EXT] Porting S3 / V4 Oberon (was: File transfer)
by Andreas Pirklbauer 03 Jan '21

03 Jan '21

> > Would EXIT, LOOP, RETURN be of any help? > > According to the post by Chris, certainly yes. These would be fairly easy to add - a few lines each in the compiler. The type-guard WITH would also be easy (map to Oberon-07 type case stmt). So *if* there is a “real” need (i.e. a *serious* effort to port V4), one may consider adding those few constructs to the compiler, with a switch. But again,..one should absolutely make sure that one uses only *one* of the two language variants, as.. "children and accounting don’t mix”!

3 4

Re (2): Porting S3 / V4 Oberon
by peter＠easthope.ca 03 Jan '21

03 Jan '21

From: Andreas Pirklbauer andreas_pirklbauer at yahoo.com Date: Sun Jan 3 03:59:16 CET 2021 > Adding back EXIT, RETURN, LOOP, etc, to the modified compiler would > certainly be doable. Thanks for stating that Andreas. It strikes me as the most optimistic sentence in the mailing list in recent months. Maybe in a year or more! > ... just too many small, subtle differences ... > You might think that it’s straightforward, but it wasn’t, at > least not in a single-pass compiler (need for fixups for method > tables, etc). I accept that absolutely. "Devil is in the details." True in any worthwhile project. One practical question I can't suppress. Are the three, EXIT, LOOP and RETURN advisable or required? In my very limited experience, removing LOOP is relatively painless. What about tolerating RETURN and EXIT but not LOOP? My knowledge is inadequate to judge the tradeoff. > But one would really need a clear motivation for doing all this > work. In my understanding there are two ways to have the old software in the new system: (1) change a large mass of software and make the new system with the new compiler in one shot. (2) Add comlexity to the new compiler; then change the mass of software incrementally. Of course (2) is more appealing to the more naive (me). I and others can help with smaller changes. Judging the tradeoff between (1) and (2) is for qualified people. Definitely beyond my qualification. Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

4 3

[EXT] Porting S3 / V4 Oberon (was: File transfer)
by Andreas Pirklbauer 03 Jan '21

03 Jan '21

> > Would EXIT, LOOP, RETURN be of any help? > > According to the post by Chris, certainly yes. Understood. But is there, or will there be, a serious (!) effort to port Linz V4? And if so, to what hardware (with enough RAM)?

2 1

Porting S3 / V4 Oberon (was: File transfer)
by Andreas Pirklbauer 03 Jan '21

03 Jan '21

> It is ironic that some of us discuss the past achievements with nostalgia, > while the others are breaking past achievements. In my view both S3 > and V4 are monumental programming achievements. No less monumental > than Ceres and the original system. Why are we thinking of preserving > the latter, while discarding the former? I see no sense whatsoever. Hi Wojtek, We have exchanged roughly similar messages on this in the past, both in the forum and privately. But to say it again: When adding back type-bound procedures to the RISC5 Oberon-07 compiler, the ability to port either e.g. Linz V4 to RISC5 was NOT (!) a goal at all (!). You seem to think this *is* or, perhaps, even “should be* a worthwhile goal. I accept that this may well be the case (for you), but it certainly wasn’t a goal when extending the Oberon-07 compiler with type-bound procedures, etc. So there is no such thing as a “surprise” that it is not not used for efforts like "porting V4" or for "bringing other Oberon-2 legacy code to RISC5". It just wasn’t a goal. And never will be (for me at least). But implementing a strict superset of Oberon-07 was.. this one was actually non-trivial. Adding back EXIT, RETURN, LOOP, etc, to the modified compiler would certainly be doable. But if someone wants to embark on such an effort, e.g. to "make porting V4 to RISC5" easier, I would only suggest that "that someone” also clearly separates the two variants of the language. I would not mix and match!! Or - as Chris has said - I would not try to eat anchovies and chocolate at the same time!! They just’s don’t mix well! Using a compiler switch to select one or (!) the other variant or at least issuing some warning messages, as you had suggested in the past, would be a way to do it. But one would really need a clear motivation for doing it all this work. If "porting V4" is one for you or that "someone else", you or that someone else can do it. But be warned: Even though it seams “easy” or at least “doable” to add back things like EXIT, RETURN, LOOP, etc, one can still (sorry again, Chris, for borrowing your expression) "die a death by a thousand cuts”. .. just too many small, subtle differences (INTEGER/REAL, standard procedures, etc etc) and just too much headache for all those little things that can get still in the way! Even when adding back type- bound procedures, I bumped into quite a few such hurdles. You might think that it’s straightforward, but it wasn’t, at least not in a single-pass compiler (need for fixups for method tables, etc). -ap

3 2

[EXT] Porting S3 / V4 Oberon (was: File transfer)
by Andreas Pirklbauer 03 Jan '21

03 Jan '21

> I wonder what else can be brought back at a moderate effort > which you would be willing to spend. I am not expecting miracles. Would EXIT, LOOP, RETURN be of any help?

2 1

Module finalization via a CLOSE language construct
by Andreas Pirklbauer 03 Jan '21

03 Jan '21

> > PS: CLOSE and Modules.Close cannot be mixed and matched. > > Is there a reason to have both, but use only one? Like for example, > easier porting of V4 finalization using Modules.Close? No, this was not a goal! I just noticed that after having added Modules.Close (i.e. a field mod.close), the CLOSE construct of Component Pascal could be added with only a few additional lines in the compiler. As I stated, this construct is just an experimental feature for now (it’s undocumented in the official documentation and may not survive..)

1 0