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

Re: [Oberon] [EXT] Re: Porting S3 / V4 Oberon (was: File transfer)
by Arthur Yefimov 03 Jan '21

03 Jan '21

Wojciech wrote: > "Lets make a nice improvement of the language, like eliminating > the EXIT. Everyone will be happy because one paragraph was > cut from the Language Report." The intention was that EXIT and RETURN statements that occour somewhere before the very end of a procedure is bad programming practice/style. If the language restricts this, the source code becomes better in the same way as when GOTO statements are replaced with WHILE statements.

2 1

Re: [Oberon] Porting S3 / V4 Oberon (was: File transfer)
by Chris Burrows 03 Jan '21

03 Jan '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@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 you My guess is that 1) has the most probability of happening but you may have other ideas. Regards, Chris Burrows CFB Software https://www.astrobe.com

2 1

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

02 Jan '21

Module finalization via a language construct CLOSE (as in Component Pascal) is now available in Extended Oberon, as an experimental feature: MODULE M; IMPORT Texts, Oberon; VAR W: Texts.Writer; PROCEDURE Start*; BEGIN (*load module M*) END Start; BEGIN Texts.OpenWriter(W) CLOSE Texts.WriteString(W, “Finalize M”); Texts.Append(Oberon.Log, W.buf) END M. ORP.Compile M.Mod/s ~ # compile M M.Start ~ # load M System.Free M ~ # unload M (prints "Finalization of M”) PS: CLOSE and Modules.Close cannot be mixed and matched.

2 1

Re (2): Oberon history.
by peter＠easthope.ca 02 Jan '21

02 Jan '21

Hello Pablo, From: Pablo Cayuela <pablo.cayuela(a)gmail.com> Date: Fri, 1 Jan 2021 23:02:58 -0300 > I thought that an entire chapter on how Oberon works on Ceres machine is > not completed right now because since Oberon was ported maybe we are all > concentrated on the other platforms (that we do have); For me there are two constraints. Information. Time. Certainly a chapter about Ceres would be desirable. > where are the original code for putting to work a Ceres computer (1, > 2, 3?) with Oberon (System 3 I guess)? > It is even mentioned on PO2013 that some parts of the original Oberon > System (bootloader?) were written in assembler, ... The easiest way is for someone with a working Ceres to donate the boot software. I don't know any individual possessing a Ceres. Probably a few remain in Europe. The Computer History Museum has more than one. A person living near the museum can become a member and initiate restoration of a Ceres to working condition. Then the boot code will be accessible. If you want to take a sabbatical year or so in California, there is a nice possibility. I live beyond commuting distance and can not volunteer for such project. The Oberon sources are in the original Project Oberon book. > I know that Ceres computers are not available easily but some > retrocomputing hobbyists gave a second chance to too many computers > and if that is the case for Oberon System on Ceres, there is a need to > have the original code and bootstrapping sequence described to > reproduce it all over. At least for study purposes or history > registers. Another possibility: the Web site you mentioned has an interesting page describing computers built with wirewrap and with breadboard wiring. http://www.cpu-ns32k.net/Gilbert.html Hypothetically, there is a possibility of recreating a Ceres machine. A further possibility: the Web site you mentioned has an interesting page about implementing(?) a NS 32xxx in FPGA. http://www.cpu-ns32k.net/FPGA.html Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

Re: File transfer;
by peter＠easthope.ca 02 Jan '21

02 Jan '21

From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> Date: Fri, 1 Jan 2021 00:24:42 +0000 > You may also want to look at the V4 modules, which are different > from what you wrote. The following modules are mentioned in the > FTP.Tool: OK, thanks. My intention was to let readers know that a wheel can be adapted rather than reinvented. > I am not seeing TFTP.Mod at all. That makes sense. ETH Oberon and V4 have FTP which is better than TFTP. Joerg demonstrated that V5 can run TFTP. Progress! > ... V4 package is sufficiently lean to give it a look for possible > port to the FPGA Oberon, ... Absolutely. Many objectives exist. All can't be tackled at once. > Ideally the Extended Oberon and Linz V4 would become source > compatible, opening the door to using all the V4 packages under FPGA > Oberon. This would be fantastic. With a bit of luck, just a matter of time. I'm still interested to get an Oberon.Ini for Linux V4. Tried emails to old addresses for Robert Lichtenberger and both bounced. Will try a few other possibilities. Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

5 9

Oberon history.
by peter＠easthope.ca 02 Jan '21

02 Jan '21

From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> Date: Fri, 1 Jan 2021 06:37:08 +0000 > How about erecting an Oberon Museum where all these conflicting > versions would wait for some history students? Interesting big challenge! For now the ETH Bibliography is restored. A relatively small task but consumed many hours. Open https://en.wikibooks.org/wiki/Oberon/ETH_Oberon/sitemap and scroll down to links "Publications" and "Authors". Many of the authors remain active. Where a suitable Web page turned up, the author name is linked. Some have dropped off the radar. Have any dropped out? Probably a few are deceased. =8~( Corrections welcome. Grüße für das neue Jahr, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

3 3

Re (2): [EXT] Re: File transfer;
by peter＠easthope.ca 02 Jan '21

02 Jan '21

From: Pablo Cayuela <pablo.cayuela(a)gmail.com> Date: Fri, 1 Jan 2021 05:38:57 -0300 > I wonder if any of you know about this site > http://www.cpu-ns32k.net/Ceres.html > http://www.cpu-ns32k.net/Oberon.html > > And the project to implement one CPU of the NS32000 family in an FPGA as a > retro computing challenge I guess > http://www.cpu-ns32k.net/Overview.html Thanks for the reminder. Vaguely remember seeing it years ago. It should be linked in the wikibook and I'm thinking about where to put it. Thanks, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

Module finalization in PO2013
by Andreas Pirklbauer 01 Jan '21

01 Jan '21

> BTW, in the TCP.Init you will see the call Kernel.InstallTermHandler(Terminate). > It means that finalization was implemented in V4. It seems to be different from > the recent Andreas' implementation. So there will be some (minor?) > incompatibilities which needs fixing. Hopefully there will be very few of these. Hi Wojtek, You’re right, there are some minor differences. The V4 implementation [1] allows one to install a finalization sequence within a *different* module. I.e. writing Kernel.InstallTermHandler(B.Terminate) in module A will in fact install procedure B.Terminate as a finalization routine of module B (!), not A. In the (proposed) Project Oberon 2013 version of module finalization this is not allowed. Nor should it be. I.e. The finalization routine must be a (parameterless) procedure declared in the *same* module In addition, it it must be installed *in* the initialization code of the module. This was done to effectively mimic the CLOSE language construct of Componenent Pascal [3]. -ap [1] V4 Linz implementation of module finalization: PROCEDURE InstallTermHandler* (h: TerminationHandler); VAR codebase, handlerAdr: LONGINT; m: Module; found: BOOLEAN; BEGIN m := modules; handlerAdr := S.VAL(LONGINT, h); found := FALSE; WHILE (m # NIL) & ~found DO codebase := S.ADR(m.code^); IF (codebase <= handlerAdr) & (handlerAdr <= codebase + LEN(m.code^)) THEN found := TRUE ELSE m := m.next END END ; IF found THEN m.term := h END END InstallTermHandler; [2] (Proposed) Project Oberon 2013 implementation of module finalization: PROCEDURE Close*(close: Command); (*set module finalization sequence*) VAR u, v, w: INTEGER; mod: Module; BEGIN u := SYSTEM.REG(LNK); mod := root; WHILE (mod # NIL) & ((u < mod.code) OR (u >= mod.imp)) DO mod := mod.next END ; (*search for caller*) IF mod # NIL THEN v := SYSTEM.VAL(INTEGER, close); SYSTEM.GET(mod.ent, w); w := mod.code + w; (*module initialization body*) IF (v >= mod.code) & (v < w) & (w <= u) THEN mod.close := close ELSE res := badclose END END END Close; See: https://github.com/andreaspirklbauer/Oberon-module-finalization [3] Component Pascal implementation of module finalization: MODULE M; PROCEDURE Init; BEGIN .. END Init; PROCEDURE Finalize; BEGIN .. END Finalize; CLOSE Finalize BEGIN Init END M.

1 0

File transfer; was, "all in one git tree"
by peter＠easthope.ca 01 Jan '21

01 Jan '21

Hi, From: =?utf-8?Q?J=C3=B6rg_Straube?= <joerg.straube(a)iaeth.ch> Date: Thu, 31 Dec 2020 12:52:51 +0100 > I transfer file to and from Oberon with tftp (RFC1350, tftp client > on OberonOS, tftp server on other side). TFTP client and server were also implemented in A2 by "be". Modules TFTP.Mod (373 lines) and Oberon.TFTPTool.Mod (51 lines) are visible. https://en.wikibooks.org/wiki/Oberon/A2#Sources,_Tools_and_Configuration_Te… TFTP.Mod has "IMPORT IP, UDP, Files, Random, KernelLog;" Random is used to find a vacant port. generator: Random.Generator; ... REPEAT INC(retries); lport := 1024 + generator.Integer() MOD 64512; NEW(socket, lport, res) UNTIL (res # UDP.PortInUse) OR (retries > MaxSocketRetries); According to https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers port 69 is assigned to TFTP. Why not use it? An incremental search might be acceptable. (* Find a vacant ephemeral port. *) lport := 60000; topPort := lport + MaxSocketTries; (* Top ephemeral port is 64738. I don't understand the origin of 64512. *) IF topPort > 64738 THEN topPort := 64738 END; NEW(socket, lport, res); WHILE(res = UDP.PortInUse) & (lport < topPort) DO INC(lport); NEW(socket, lport, res) END; A FPGA board connects to the server by a serial crossover cable. Analogously for an emulated V5 machine. In linux at least, a server is readily available. https://wiki.debian.org/TFTP Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1