February 2020 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Coding practice
by Chris Burrows 24 Feb '20

24 Feb '20

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Skulski, Wojciech > Sent: Friday, 21 February 2020 1:20 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Coding practice [Was: Re: Hennessy.Mod 64kB > limit] > > Joerg: > > let's strike a deal: > > IF > a[i] > a[i+1] THEN temp := a[i]; a[i] := a[i+1]; a[i+1] := temp > END; > > > If the code gets too complex, I either use more lines (if speed is > important) or I create a procedure. > The guys at Oberon microsystems published a set of Programming Conventions for Oberon/L a.k.a. Component Pascal. It is included in the Help file with the Blackbox Component Pascal system. Several possible styles i.e. multiple statements on one line, statements split over several lines etc. are considered to be good practice. Thankfully, nobody is forced or constrained by the Oberon language itself (unlike some languages) to use a prescribed programming style. Rather than inventing our own programming conventions, we adopted those, with the kind permission of Oberon microsystems, for the Astrobe development system. If you do not have access to the original Blackbox document refer to Chapter 8. 'Programming Conventions and Guidelines' in the 'ARM Cortex-M Oberon Programmers Guide' which you can download from: https://www.astrobe.com/Oberon.htm When I'm writing new code from scratch then I use my own personal preferences (which can change from one month to another!) However, if I am making minor modifications to existing code I try to follow the principle of 'when in Rome do as the Romans do' and adopt a similar style to the original author. If these principles are not followed the result can be code that looks as ugly as a one-page document written in 17 different fonts. Regards, Chris Burrows CFB Software https://www.astrobe.com

6 12

Module aliases - what is the correct way to handle them
by Andreas Pirklbauer 23 Feb '20

23 Feb '20

Hi Paul, I’ve now fully bought into your proposal to make ORB.ThisModule a tick less restrictive by no longer checking the two "cross-combinations" (obj.orgname # name) and (obj.name # orgname) that I had originally proposed for the first WHILE loop in ThisModule - as I have now verified that this omission indeed merely (and safely) re-allows the following cases: MODULE B10; IMPORT X := M, M := M0; END B10. (*reuse M as alias*) MODULE B11; IMPORT M := M0, M0 := M; END B11. (*swap M and M0*) MODULE B12; IMPORT M0 := M, X := M0; END B12. (*reuse M0 as canonical*) However, am still a bit uncomfortable with *always* generating “invalid import error” ... ELSE (*module already present*) IF non THEN ORS.Mark("invalid import order") END END ; I would therefore like to propose the following as a minimum change to your proposed solution, which (a) not only fixes the current bug in ORB.Mod bug, but (b) also outputs the “appropriate” error message in *all* possible cases: PROCEDURE ThisModule(name, orgname: ORS.Ident; non: BOOLEAN; key: LONGINT): Object; VAR mod: Module; obj, obj1: Object; BEGIN obj1 := topScope; obj := obj1.next; (*search for module*) WHILE (obj # NIL) & (obj(Module).orgname # orgname) DO obj1 := obj; obj := obj1.next END; IF obj = NIL THEN (*new module, search for alias*) obj := topScope.next; WHILE (obj # NIL) & (obj.name # name) DO obj := obj.next END ; IF obj = NIL THEN (*insert new module*) NEW(mod); mod.class := Mod; mod.rdo := FALSE; mod.name := name; mod.orgname := orgname; mod.val := key; mod.lev := nofmod; INC(nofmod); mod.dsc := NIL; mod.next := NIL; IF non THEN mod.type := noType ELSE mod.type := nilType END ; (*!*) obj1.next := mod; obj := mod ELSIF non THEN IF obj.type.form = NoTyp THEN ORS.Mark("mult def") ELSE ORS.Mark("invalid import order") END ELSE ORS.Mark("re-import impossible") (*conflict with alias*) END ELSIF non THEN (*module already present and explicit import*) IF obj.type.form = NoTyp THEN ORS.Mark("mult def") ELSE ORS.Mark("invalid import order") END END ; RETURN obj END ThisModule; (= http://github.com/andreaspirklbauer/Oberon-test-module-aliases/blob/master/…) The set of possible cases, together with their error messages, is shown below in the appendix. Apart from the different error messages, the only difference to your proposed solution is to assign mod.type := noType, when an explicit import is inserted for the first time, and mod.type := nilType, when a re-import is inserted for the first time. This tiny change allows one to easily identify (and check for) each possible case individually, when the same module name is encountered again. Thanks to the discussion with yourself, Luca, Jörg and several others, there now is even a complete proof that this indeed works in *all* possible cases. It is about as boring as it gets, but in case you can actually endure it (yawn), there it is.. http://github.com/andreaspirklbauer/Oberon-test-module-aliases/blob/master/… The set of test cases itself is listed below, together with the compiler message, or at: https://github.com/andreaspirklbauer/Oberon-test-module-aliases/blob/master… I also felt that re-allowing *single* aliases for the cases B10, B11 and B12, as described above, while at the same time continuing to disallow *multiple* aliases to the same module, was a sensible choice as it requires only minimal changes to the current FPGA Oberon implementation. PS: Turns out that multiple aliases could also be easily be added (with ~20 additional lines, see ORB10 in the above repository), but I felt this would be overkill. Who needs more than one alias? What do you think ? Andreas Appendix: Test cases, together with the “appropriate” error messages: --------------------------------------------------------------------- MODULE M; TYPE T0* = RECORD i: INTEGER END ; END M. MODULE M0; TYPE T0* = RECORD i: INTEGER END ; END M0. (*B0 is correct*) MODULE B0; IMPORT M0, X := M1; END B0. (*no error message*) (*B1-B5 are definitely erroneous*) MODULE B1; IMPORT M, M; END B1. (*mult def*) MODULE B2; IMPORT M, M := M0; END B2. (*mult def*) MODULE B3; IMPORT M := M0, M; END B3. (*mult def*) MODULE B4; IMPORT M := M0, M := M0; END B4. (*mult def*) MODULE B5; IMPORT X := M, X := M0; END B5. (*mult def*) (*B6-B9 depend on the implementation - some allow these cases, others don't*) MODULE B6; IMPORT M, X := M; END B6. (*mult def*) MODULE B7; IMPORT X := M, M; END B7. (*mult def*) MODULE B8; IMPORT M, X := M, Y := M; END B8. (*mult def*) MODULE B9; IMPORT X := M, Y := M; END B9. (*mult def*) (*B10-B12 can safely allowed by not checking obj.orgname # name and obj.name # orgname*) MODULE B10; IMPORT X := M, M := M0; END B10. (*no error message*) MODULE B11; IMPORT M := M0, M0 := M; END B11. (*no error message*) MODULE B12; IMPORT M0 := M, X := M0; END B12. (*no error message*) (*B13-B16 test re-imports*) MODULE B13; IMPORT M0, M1; END B13. (*no error message*) MODULE B14; IMPORT M := M0, M1; END B14. (*no error message*) MODULE B15; IMPORT M0 := M, M1; END B15. (*re-import impossible*) MODULE B16; IMPORT M1, M0 := M; END B16. (*invalid import order*) MODULE B17; IMPORT M1, M0; END B17. (*invalid import*)

1 0

Re: [Oberon] Fwd: IDE with integrated source leveldebuggerandLuaJITVM running the Oberon System
by rochus.keller＠bluewin.ch 20 Feb '20

20 Feb '20

@ all I added some application modules (Sierpinski etc.) to my Oberon System version and implemented additional procedures in the backend to support them; the system is now running quite well from my point of view; here is a screenshot: http://software.rochus-keller.info/screenshot_oberon_system_on_luajit.png Here is the link to the most recent Windows binary: http://software.rochus-keller.info/OberonIDE_win32.zip Please use https://github.com/rochus-keller/OberonSystem/issues or https://github.com/rochus-keller/Oberon/issues (for the compiler and the IDE) in case you have feedback or questions. Best R.

8 17

Re: [Oberon] Fwd: IDE with integrated source leveldebuggerandLuaJIT VM running the Oberon System
by rochus.keller＠bluewin.ch 20 Feb '20

20 Feb '20

@ all There is now also an executable version of the Oberon IDE for macOS x86_64 (>= El Capitan). If you want to try it, download and mount this DMG: http://software.rochus-keller.info/OberonIDE_macOS_x64.dmg . Remember that on Mac the CTRL+key shortcuts are mapped to the Command key. I also uploaded the most recent version of the Windows binary: http://software.rochus-keller.info/OberonIDE_win32.zip . Thanks to the LuaJIT FFI API, the generated code now runs almost as fast as the C code generated by OBNC and optimized with GCC; and there is even more potential for optimization. Best R.

1 0

Module aliases - what is the correct way to handle them
by Andreas Pirklbauer 19 Feb '20

19 Feb '20

Hi Paul, Just as an addendum to your proposed solution (ORB06): Below are the two cross-combinations that you have removed relative to the version which checks all 4 possible combinations (as in ORB08 of http://github.com/andreaspirklbauer/Oberon-test-module-aliases) 1. The first cross-combination (obj.orgname # name) can indeed be ignored, as it safely allows: MODULE B10; IMPORT X := M0, M0 := M1; END B10. (*obj = X (=M0) => obj.orgname = M0, name = M0*) MODULE B11; IMPORT M := M0, M0 := M; END B11. (*obj = M (=M0) => obj.orgname = M0, name = M0*) 2. The second cross-combination (obj.name # orgname) can also be ignored, as it safely allows: MODULE B12; IMPORT M0 := M, X := M0; END B12. (*obj = M0 (=M) => obj.name = M, orgname = M0*) In all these cases (B10, B11, B12), these can be seen as legal and also can be handled by the FPGA Oberon data structure. The only remaining question seems to be whether can/should improve the error messages in some cases. -ap

1 0

Module aliases - what is the correct way to handle them
by Andreas Pirklbauer 19 Feb '20

19 Feb '20

Hi Paul, Thank you (and Luca, Jörg and several others..) very much for your great input on the import alias feature in the Oberon-07 FPGA RISC compiler! > Thanks to your discussions, we know this doesn't allow the more exotic > combinations and uses of imports and aliases discussed, but supporting > those would presumably require changing the current implementation's > single-alias-to-module mapping (type ORB.Module). You’ right. The one edge case I can think of that could still be supported by the current data structure of FPGA Oberon - which doesn’t multiple aliases per module - is to re-use a module name *after* it has already been imported under an alias name, as in: MODULE B10; IMPORT M := M0, M0 := M1; END B10. MODULE B11; IMPORT M := M0, M0 := M; END B11. (*swaps M & M0*) PS: Your solution proposed in an earlier post (ORB06) actually allows these, while my current, more restrictive, solution (ORB08) doesn’t. But if one wants to support *multiple aliases* per module, FPGA Oberon just cannot handle it. But supporting it would be simple, e.g. just define: primary instance => mod.lev > 0 secondary instance => mod.lev = 0 and mod.dsc points to primary instance where the primary instance can be a proper module or itself be an alias. Then, additional aliases just get added as secondary instances, and the check whether a module entry in the topScope is a secondary instance is: IF (mod.dsc # NIL) & (mod.dsc.class = Mod) THEN .. secondary instance .. See, for example, the modules starting at ORB09.Mod at http://github.com/andreaspirklbauer/Oberon-test-module-aliases PS: This small experiment was conducted, just to see what it *would* take, not to suggest its introduction in a particular compiler.

1 0

Question: what Oberon System is shown here?
by Frans-Pieter Vonck 18 Feb '20

18 Feb '20

https://youtu.be/AZdcaLWPAd8?t=1382 Any Ideas? Greets, Frans-Pieter Vonck

3 4

Module aliases - what is the correct way to handle them
by Andreas Pirklbauer 18 Feb '20

18 Feb '20

Paul, I have added your proposal below as (the new version of) the file ORB06.Mod at: http://github.com/andreaspirklbauer/Oberon-test-module-aliases Your proposal reads: PROCEDURE ThisModule(name, orgname: ORS.Ident; non: BOOLEAN; key: LONGINT): Object; VAR mod: Module; obj, obj1: Object; BEGIN obj1 := topScope; obj := obj1.next; (*search for module*) WHILE (obj # NIL) & (obj(Module).orgname # orgname) DO obj1 := obj; obj := obj1.next END; IF obj = NIL THEN (*new module - search for name/alias*) obj := topScope.next; WHILE (obj # NIL) & (obj.name # name) DO obj := obj.next END ; IF obj = NIL THEN (*insert new module*) NEW(mod); mod.class := Mod; mod.rdo := FALSE; mod.name := name; mod.orgname := orgname; mod.val := key; mod.lev := nofmod; INC(nofmod); mod.type := noType; mod.dsc := NIL; mod.next := NIL; obj1.next := mod; obj := mod ELSE ORS.Mark("mult def") END ELSE (*module already present*) IF non THEN ORS.Mark("invalid import order") END END ; RETURN obj END ThisModule; I have tested it against the test modules B0-B11 in the test file M.Mod (this suite is designed such that B0 should always be correct, B1-B5 should return “mult def” and the reminaing modules should issue error msgs depending on the implementation of ORB) MODULE B0; IMPORT M0, X := M1; END B0. MODULE B1; IMPORT M0, M0; END B1. MODULE B2; IMPORT M0, M0 := M1; END B2. MODULE B3; IMPORT M0 := M1, M0; END B3. MODULE B4; IMPORT M0 := M1, M0 := M1; END B4. MODULE B5; IMPORT M0 := M1, M0 := M2; END B5. MODULE B6; IMPORT M0, X := M0; END B6. MODULE B7; IMPORT X := M0, M0; END B7. MODULE B8; IMPORT M0, X := M0, Y := M0; END B8. MODULE B9; IMPORT X := M0, Y := M0; END B9. MODULE B10; IMPORT X := M0, M0 := M1; END B10. MODULE B11; IMPORT M0 := M1, M1 := M0; END B11. with the following results: ORP.Compile ORB06.Mod/s ~ System.Free ORP ORG ORB ~ now recompile B0-B11 -> B0: compiles -> B1: does not compile - reports "invalid import order" -> B2: does not compile - reports "mult def" -> B3: does not compile - reports "mult def" -> B4: does not compile - reports "mult def", reports "invalid import order" -> B5: does not compile - reports "mult def" twice -> B6: does not compile - reports "invalid import order" -> B7: does not compile - reports "invalid import order" -> B8: does not compile - reports "invalid import order" twice -> B9: does not compile - reports "invalid import order" -> B10: compiles -> B11: does not compile - reports "mult def" Is this what you intended? I guess that at least B1 should also return “mult def”. Meanwhile, I have improved my ORB07.Mod to make it cleaner, by separating the cases of “explicit import” and “re-import” --> see ORB08.Mod. -ap ----------------------------------------------------------------------------------- > I'm still a bit uncomfortable with your loop which tests both canonical > names and aliases at the same time in your ORB07.Mod suggestion: > > WHILE (obj # NIL) & (obj.name # name) & (obj.name # orgname) & > (obj(Module).orgname # orgname) & (obj(Module).orgname # name) > DO ... > > and would like to propose the following as a minimum change, which fixes > the current ORB.Mod bug and adds the "mult def" check required to catch > a re-use of an alias: > > # WHILE (obj # NIL) & (obj(Module).orgname # orgname) DO obj1 := obj; > obj := obj1.next END; > IF obj = NIL THEN (*new module - search for name/alias*) > + obj := topScope.next; WHILE (obj # NIL) & (obj.name # name) DO obj > := obj.next END ; > + IF obj # NIL THEN ORS.Mark("mult def") > + ELSE > NEW(mod); mod.class := Mod; mod.rdo := FALSE; > mod.name := name; mod.orgname := orgname; mod.val := key; > mod.lev := nofmod; INC(nofmod); mod.type := noType; > mod.dsc := NIL; mod.next := NIL; > obj1.next := mod; obj := mod > + END > ELSE (*module already present*) > IF non THEN ORS.Mark("invalid import order") END > END ;

1 0

Re: [Oberon] Coding practice [Was: Re: Hennessy.Mod 64kB limit]
by rochus.keller＠bluewin.ch 18 Feb '20

18 Feb '20

@ August Karlstrom >> Is this simply "the Swiss way" of saving lines? Well, I'm Swiss and I don't like this practice either. This not only makes the code more confusing but also makes it harder to step or set breakpoints. Best R. _______________________________ From: August Karlstrom Sent on: Tue, 18 Feb 2020 18:45:28 +0100 To: oberon(a)lists.inf.ethz.ch Cc: Subject: [Oberon] Coding practice [Was: Re: Hennessy.Mod 64kB limit] ... I'm also a bit curious about the practice of putting several statement on the same line. This is something I have not seen in other languages. Is this simply "the Swiss way" of saving lines? To me it makes the logic harder to follow. -- August

1 0

Re: [Oberon] Hennessy.Mod 64kB limit
by rochus.keller＠bluewin.ch 18 Feb '20

18 Feb '20

We also like to confuse friends ;-) ------------------------ Skulski, Wojciech wrote: .... If the purpose of programming is to confuse the enemy, then everything is OK of course. (The enemy being everyone except the author.) W

1 0