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

Dynamic type of record var parameter
by Andreas Pirklbauer 12 Jan '21

12 Jan '21

> My understanding is that you need to use a type guard to > assert that p can be assumed to have a dynamic type of p2: > > i.e. p := q; check(p(p2)^); > This would indeed produce the correct output (“is p2” instead of “is p0”) in the provided test program. However, the correct dynamic type could also be passed by the compiler instead of relying on the programmer to “know” what the dynamic type is. To fix this in the compiler, one needs to change procedure ORG.VarParam From: PROCEDURE VarParam*(VAR x: Item; ftype: ORB.Type); VAR xmd: INTEGER; BEGIN .. .. ELSIF ftype.form = ORB.Record THEN IF xmd = ORB.Par THEN Put2(Ldr, RH, SP, x.a+4+frame); incR ELSE loadTypTagAdr(x.type) END END END VarParam; To: PROCEDURE VarParam*(VAR x: Item; ftype: ORB.Type); VAR xmd: INTEGER; BEGIN .. .. ELSIF ftype.form = ORB.Record THEN IF x.deref THEN Put2(Ldr, RH, 0, -8); incR (*pass the dynamic type rather than the static type*) ELSIF xmd = ORB.Par THEN Put2(Ldr, RH, SP, x.a+4+frame); incR ELSE loadTypTagAdr(x.type) END END END VarParam; and make a few other small modifications to set x.deref whenever a pointer has been dereferenced. The full solution can be found here: http://github.com/andreaspirklbauer/Oberon-allow-dereferenced-pointer-as-va… Andreas

2 1

Dynamic type of record var parameter
by chris 12 Jan '21

12 Jan '21

Hello, please consider the following test of dynamic type of record variable parameters: MODULE Test; IMPORT Texts, Oberon; TYPE r0 = RECORD i : INTEGER; END; r1 = RECORD (r0) x : REAL END; r2 = RECORD (r1) c : CHAR END; p0 = POINTER TO r0; p1 = POINTER TO r1; p2 = POINTER TO r2; VAR W : Texts.Writer; PROCEDURE check(VAR r : r0); BEGIN IF r IS r2 THEN Texts.WriteString(W, "is r2") ELSIF r IS r1 THEN Texts.WriteString(W, "is r1") ELSIF r IS r0 THEN Texts.WriteString(W, "is r0") END; Texts.WriteLn(W) END eins; PROCEDURE do* (); VAR p : p0; r : r0; q : p2; t : r2; BEGIN NEW(p); NEW(q); check(t); check(p^); check(q^); p := q; check(p^); Texts.Append(Oberon.Log, W.buf); END do; BEGIN Texts.OpenWriter(W); END Test. Output from Oberon 2013 emulator is: is r2 is r0 is r2 is r0 What surprises me is the last one. The dynamic type is r2 not r0. It looks like the compiler uses the static type from the local variable p instead of the dynamic type of p^. Is this intended behavior? Greetings, chris

4 3

Dynamic type of record var parameter
by Andreas Pirklbauer 12 Jan '21

12 Jan '21

> VAR p : p0; r : r0; q : p2; t : r2; > > p := q; check(p^); This is a known issue in the Project Oberon 2013 compiler: It just does *not* handle the case where the actual parameter of a procedure is a dereferenced pointer p^. PS: The Ceres-Oberon compiler handled this correctly (‘wasderef'): PROCEDURE Param*(VAR ap: OCT.Item; f: OCT.Object); .. ELSIF (.. (ap.mode = RegI)) & (ap.obj = OCC.wasderef) (*<--*) THEN (*actual par is p^*) … END To fix this in the Project Oberon 2013 compiler, one would first need to “remember”, whether a procedure parameter has in fact been dereferenced or not. That part is easy: you just do so, e.g. by keeping track of calls to ORG.DeRef in ORP.selector: PROCEDURE selector(VAR x: ORG.Item; VAR …; deref: BOOLEAN; (*keeps track of dereferenced pointers*) BEGIN deref := FALSE; WHILE (sym = ORS.lbrak) OR (sym = ORS.period) OR (sym = ORS.arrow) OR (sym = ORS.lparen) & (x.type.form IN {ORB.Record, ORB.Pointer}) DO IF sym = ORS.lbrak THEN ... Check(ORS.rbrak, "no ]”); deref := FALSE ELSIF sym = ORS.period THEN ORS.Get(sym); IF sym = ORS.ident THEN IF x.type.form = ORB.Pointer THEN ORG.DeRef(x); x.type := x.type.base; deref := TRUE END ; IF x.type.form = ORB.Record THEN ... IF obj # NIL THEN ORG.Field(x, obj); x.type := obj.type; deref := FALSE ELSE … END ... END ... END ELSIF sym = ORS.arrow THEN ... IF x.type.form = ORB.Pointer THEN ORG.DeRef(x); x.type := x.type.base; deref := TRUE ... END ... END END END selector; The problem now is how to *store* the value of “deref" in the item x itself. In Ceres-Oberon, the field x.obj was “abused” for this purpose. But when transitioning from Ceres-Oberon to PO2013-Oberon, several item fields were eliminated, among them also the back pointer field x.obj. So the baby was flushed down with the washing water.. ;-) Unfortunately, there is no other item field that one could use to encode the fact that an item x has been dereferenced (all fields are taken), so one would need to add back one, e.g. an extra field x.c. Assuming this is done, one could then use this field in ORG.VarParam, similar to how the Ceres Oberon compiler does it in OCH.Param: PROCEDURE VarParam*(VAR x: Item; ftype: ORB.Type); VAR xmd: INTEGER; BEGIN xmd := x.mode; loadAdr(x); IF (ftype.form = ORB.Array) & (ftype.len < 0) THEN (*open array*) ... ELSIF ftype.form = ORB.Record THEN IF x.c > 0 THEN (*deref*) (*use dynamic type, not static type*) ... END END END VarParam; There are other ways to solve this, for example by introducing another VAR parameter “deref” to ORP.selector: PROCEDURE selector(VAR x: ORG.Item; VAR deref: BOOLEAN); to pass around the value of deref within the compiler. But then one would need to also add the same parameter in several other places in the compiler as well, e.g. expression/term/factor… It can all be done, but it just hasn’t. Perhaps someone finds a more elegant way of handling this case.. Any takers??

1 0

Re: [Oberon] LOOP conversion
by Chris Burrows 12 Jan '21

12 Jan '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Skulski, Wojciech > Sent: Thursday, 7 January 2021 1:53 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] [EXT] LOOP conversion > > Andreas: > > >I have a sneaking suspicion that the participants in this discussion > >have (probably?) already spent more time on this question than the > time > >it would take to add LOOP to the compiler ;-) > > I would if I could. But there are some limits to my knowledge and > skills. I know how to do many things, but not this one. > > Other users are in a similar situation. Not every user is capable to > define a language and to implement or change the compiler. > > We are at your mercy. > I believe in that clichéd quote "Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime". How much of your time would you be prepared to invest to learn how to add LOOP and multiple EXITs to Wirth's published Project Oberon Oberon-07 compiler? If you give a reasonable answer I am prepared to give you (and anybody else watching this list) step by step instructions of the approach you can take to achieve it. As far as compiler modifications go it is relatively straightforward. The completed exercise consists of approximately 20 additional statements in two of the compiler modules and makes use of existing code generation procedures. Once you have completed those steps you should have learnt enough to be able to add multiple RETURNs as well with little or no assistance and to make similar changes to Andreas's source code if you want to build on that instead. Step 1. Prepare an environment to allow you to edit the compiler source code, compile it and execute it. I expect that you will find it to be a very empowering exercise. The only fear I have is that once "the genie is out of the bottle" there will be no putting it back ;-) Regards, Chris Burrows https://www.astrobe.com

4 5

More links/versions
by Liam Proven 12 Jan '21

12 Jan '21

I found some more interesting info while attempting to research the previous thread. I knew that Oberon ran on DOS, but I found a page with some documentation and old (circa 1995) downloads: https://sourceforge.net/projects/dosoberon/files/DOS%20Oberon%20System%203%… I also found some recent instructions for FreeDOS 1.2 and VirtualBox 6: https://rsdoiel.github.io/blog/2019/07/28/freedos-to-oberon-system-3.html -- Liam Proven – Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk – gMail/gTalk/gHangouts: lproven(a)gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

3 2

Re (2): Text in V4.
by peter＠easthope.ca 11 Jan '21

11 Jan '21

From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> Date: Mon, 11 Jan 2021 04:45:19 +0000 > > Translation of a fold element to a collapsible element in HTML5 might > > be possible. > > Why would you want to do this? Unexpected question. Please open this. https://en.wikibooks.org/wiki/Oberon/ETH_Oberon#Module_Sources_and_Tools_in… There you can see a small selection of source files. To read one of them, simply click or tap on it. You can use a good old desktop machine running MS Windows or Linux or MacOS. You can use a tablet. You can use a smartphone. Demographic data here. https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_… https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Mobile_devic… Client device independence is possible by giving the browser responsibility for presentation. The server provides content with optional default presentation. The client browser presents according to capabilities. The significance of client device indepedence is illustrated by attempting to read a fixed format text on a small screen. You will need good eyes to read small typography. Alternatively you need the patience and time to scroll left and right while reading larger typography. The objective of documentation is to help a reader understand a topic. To be effective, documentation must be available and accessible. The Web is now the most ubiquitous medium for public distribution of information. https://en.wikipedia.org/wiki/World_Wide_Web Of course we can insist "If you are interested in Oberon, just install Oberon {V4, V5 ...} on your {MS Windows desktop system, Digilent Xilinx xyz, ...}. Within the system read all *.Mod, *.Text and*.Tool files. Then you will know all about it." Or a variation of that. A difficult approach. There is no necessity for it. No offense intended but I'm afraid that approach will guarantee Oberon becoming more obscure. Why condemn a good idea? =8~( Why not allow it to flourish? =8~) I don't mean to rant. Certainly to be emphatic. Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0

Re: [Oberon] Text in V4.
by Chris Burrows 11 Jan '21

11 Jan '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > peter(a)easthope.ca > Sent: Monday, 11 January 2021 2:39 PM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Re (2): [EXT] Text in V4. > > From: =?utf-8?Q?J=C3=B6rg_Straube?= <joerg.straube(a)iaeth.ch> > Date: Sun, 10 Jan 2021 22:09:09 +0100 > > ... > > - The Fold elements you found already > > - Version elements allow you to have different versions (e.g. > > Emulator1, Emulator2, FPGA) in the same source file > > To my understanding those are the only elements appearing in module > sources. > > Translation of a fold element to a collapsible element in HTML5 might > be possible. > > I've yet to find an example of a version element. Folds are obvious > in WebFTP.Mod. If versioning is there, I don't recognize it. > > Thx, ... P. L. > On the Windows version of Linz V4, the module TextFrames, for example, has PowerMac, Linux and Windows versions all in the same source file. The second line in the source code shows something like this: (*<PowerMac>* When you click with the middle-mouse on the '<' marker you get a popup menu with each of the three operating systems to choose from. The source code changes depending on which one you use. In the body of the source code file each section that is dependent on these three choices is bracketed with < ... > Regards, Chris Burrows CFB Software https://www.astrobe.com

1 0

Re (2): [EXT] Text in V4.
by peter＠easthope.ca 11 Jan '21

11 Jan '21

From: =?utf-8?Q?J=C3=B6rg_Straube?= <joerg.straube(a)iaeth.ch> Date: Sun, 10 Jan 2021 22:09:09 +0100 > ... > - The Fold elements you found already > - Version elements allow you to have different versions (e.g. > Emulator1, Emulator2, FPGA) in the same source file To my understanding those are the only elements appearing in module sources. Translation of a fold element to a collapsible element in HTML5 might be possible. I've yet to find an example of a version element. Folds are obvious in WebFTP.Mod. If versioning is there, I don't recognize it. Thx, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

Re: [Oberon] Java byte-code and Pascal P-Code (was: Text in V4.)
by Arthur Yefimov 11 Jan '21

11 Jan '21

Chris Burrows wrote: > I believe an Oberon version, O-Code, was used in lectures > at ETH in the 2000's. Also the same P-Code / M-Code / O-Code learning technique is used now, in 2021, in Vologda State University, Russia, by S. Z. Sverdlov. The whole computer science course/module is available on YouTube (in Russian language). I. e. here is the lecture where Oberon-0 compiler to O-Code is written using Python and then Oberon-0 programs are being run: https://youtu.be/OQQBVEg2KWA?t=2689

1 0

_Compiler_Construction_ by Niklaus Wirth
by Andreas Pirklbauer 10 Jan '21

10 Jan '21

> >I would have thought Andreas would be the most appropriate person to > >document his techniques? > > Of course! It would be absolutely wonderful to order his book(s) from Amazon! You’ll have to contend with web/github pages for the time being ;-) But some comments: 1. From a system point of view, most is actually already described, but unfortunately not in one place - either as README in various repositories or in pdf form (eg safe module unloading, fast access to global and imported module data, batch execution, etc) 2, From a language point of view, much is there as well in various repositories (so, again distributed…) But not all. The one big thing missing is how to implement type-bound procedures in a single- pass (!) compiler. That one was quite tricky and would require time to properly document. The documentation actually exists and is quite complete, but it’s not in polished-enough form. PS: Once the RISC-V version of EOS will be released, there will also be more extensive PDF documentation, e.g. on a "multi-compiler that targets two target architectures”. -ap

1 0