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

Re: [Oberon] Emulators
by Jörg 14 Feb '22

14 Feb '22

Wojtek > How can I proceed, in practical terms, to use your JS emulator for development? Perhaps we should start discussing, WHAT you want to change. At the moment I see three different levels of HW modifications: easy, more difficult, impossible. Basically, see an emulator as virtualization. In virtualization you have a host machine (where the emulator runs on) and a guest machine (this is the FPGA board). I ignore „containers“ at the moment Easy: if you want to extend the RISC-5 instruction set in Verilog (eg add an autoincrement instruction) the modification of the emulator is rather straight forward. I neglect the fact that you have to modify the Oberon-07 compiler to use this new instruction, because this is not important for the emulator. More difficult: if you want to add IO mapped HW (eg Ethernet or Wifi) or memory mapped HW (eg color display) to your FPGA and the host machine has an equivalent of this HW, with a little bit of effort the emulator can be modified to map the IO register commands or new memory layout to the corresponding host HW. Impossible: if you want to add HW to your FPGA and the host machine does not have an equivalent HW (eg a neutrino sensor) then it‘s impossible for the emulator to mimic the new FPGA HW. br Jörg

7 33

Wanted: Oberon Syntax in TextMate, Sublime Text or Atom Grammar
by Treutwein Bernhard 01 Jan '22

01 Jan '22

Does somebody have grammars for Oberon / Oberon-2 / Component Pascal / Active Oberon as grammar for TextMate / Sublime Text / Atom Background: Github wrongly classifies Oberon / Oberon-2 / Component Pascal / Active Oberon as Modula-2. I opened quite some tiome ago an issue in the github/linguist project (https://github.com/github/linguist/issues/3888) and they don't accept EBNF grammars. -- Bernhard Treutwein

6 9

Ofront+
by Oleg N. Cher 25 Dec '20

25 Dec '20

Dear Oberoners, I'm really surprised that many people here are hearing about Online Oberon for the first time. I've known about it for a long time. In order to inform the public, I want to tell you about my own fork of Josef Templ's project Ofront: https://github.com/jtempl/ofront/ Ofront+ is a direct continuation of the ideas embedded in the Ofront project. But it expands number of supported Oberon dialects: Oberon/Oberon-2 Oberon-07/16 (support is still in-work, but users need to encourage this direction) Component Pascal (almost everything is supported except 2-byte CHAR type, even some GPCP extensions) Oberon-3 (experimental dialect with constant arrays and "proper FOR") We can also use multiple dialects in a single project. Ofront+ also increases the number of available target architectures: BlackBox Component Builder FreeBSD amd64 Linux amd64 Linux armv7 Linux i386 OpenBSD amd64 OpenBSD armv7 OpenBSD i386 macOS X MS Windows 32 bits MS Windows 64 bits Ofront+ was tested and used with C compilers: GCC/MinGW, 32/64 bits Clang SDCC (Small Device C Compiler) Tiny C (tcc) cc65 (for CPU 6502) The latest build of Ofront+ you can get here: https://github.com/Oleg-N-Cher/OfrontPlus I have been working on this for many years and try to keep the project afloat all the time. It's not very documented and it's not covered by a huge set of tests, but I do what I can based on my modest strength. I didn't plan to go that far, I just needed to make a few changes. Then I wanted to make support for Windows. Now we have the result of this work. I still want to do a lot before the release of version 1.0, but this is already quite stable. I won't tell you very much about the differences, but users say that I went too far. ;-) Ofront+ comes as a subsystem for BlackBox and as command line tool (Oberon-like GUI not implemented). So welcome, please use, write reviews and suggestions. Also I provide support for free. I want to thank Josef Templ, who actively supported me and helped me solve many problems. I also want to thank Stewart Greenhill, who made useful improvements and helped fix problems, and developed his own tools for Ofront+. List of differences and improvements: https://github.com/Oleg-N-Cher/OfrontPlus/blob/master/Readme.txt -- Oleg N. Cher

6 11

A technote for automatically running batch job on system startup
by Charles Perkins 23 Dec '20

23 Dec '20

Hello everybody, I wrote a note on how to have Oberon automatically run a startup script. I introduced two small changes to TextFrames.Mod (five lines total) introducing a 'Call Message' and then handling that message with a call to the Call procedure, and three small changes to System.Mod (eight lines total) introducing two variables, opening a viewer with a predetermined text file, and then sending the call message to the viewer at the end of system initialization. https://github.com/io-core/technotes/blob/main/technote013.md I used Michael Schierl's Batch.Mod for the actual batching of commands but Andreas Pirklbauer's system would have worked just as well, or any other batching or script system. The above changes merely call the first command in a text file, the rest of what happens is up to that command. I did this to make building and testing my own system more automatic but I thought I'd share in case anyone found it interesting or useful Best Regards, Chuck

5 5

Serious type loophole in type case statements and a possible fix
by Andreas Pirklbauer 31 Oct '20

31 Oct '20

I thank “the community” for the emails on this topic. I have condensed the feedback to the new tentative definition of the type case statement below, and implemented it. Of course, this is not a clean definition of this language construct anymore, but at least it’s one with no more type loopholes in it. The only remaining question is, in my view, just how much faster a “typical” program is by using *this* implementation. If the answer is “not much faster”, I’m in favour of eliminating the type case statement Anyone volunteering to do some benchmarking? The link to the implementation is below. * New (tentative) definition of the type case statement * * CASE x OF * T1: S1 * | T2: S2 * ELSE S3 * END * * It is modified such that it implements the following rules and restrictions: * * - Case variables must be simple identifiers that cannot be followed by selectors, i.e. they cannot * be elements of a structure (such as array elements or record fields). * - If the type of the case variable is a record type, the case variable must be a variable * parameter of the procedure containing the type case statement. * - If the type of the case variable is a pointer type, the case variable must be either a local * variable or a value parameter passed to the procedure containing the type case statement, * and the case variable cannot itself be passed as a variable parameter to another procedure. * - Assignments to case variables within the body of a type case statement are not allowed * (however, assignments to individual fields of case variables are allowed). * * Such a type case statement disallows... * * 1. Case variables that are elements of a structure * 2. Global case variables * 3. Local case variables of a record type * 4. Case variables that are variable parameters of a pointer type * 5. Passing a case variable of a pointer type as a variable parameter to another procedure * 6. Assignments to case variables within the body of the type case statement * * but allows... * * 1. Local pointer variables as the case variable * 2. Value parameters of a pointer type as the case variable * 3. Variable parameters of a record type as the case variable * 4. Assignments to individual fields x.f of a case variable x * 5. Passing a case variable of a pointer type as a *value* parameter to another procedure * 6. Passing a case variable of a record type as a *value* parameter to another procedure * 6. Passing a case variable of a record type as a *variable* parameter to another procedure Implementation and documentation (the first link is an implementation for Project Oberon 2013): http://github.com/andreaspirklbauer/Oberon-type-case-statement-without-loop… http://github.com/andreaspirklbauer/Oberon-extended/blob/master/Documentati…

1 0

Serious type loophole in type case statements and a possible fix
by Andreas Pirklbauer 30 Oct '20

30 Oct '20

Correction: A case variable of a type case statement can now only be one of the following: 1. Local pointer variables 2. Pointer value parameters 3. Record VAR parameters -ap ———————————— This case below is now also caught by the modified compiler at [*]. A case variable of a type case statement can now only be one of the following: 1. Local variables (pointer or record) 2. Pointer value parameters 3. Record VAR parameters -ap [*] http://github.com/andreaspirklbauer/Oberon-type-case-statement-without-loop… > When the compiler automatically generates a type guard (ORG.TypeTest) > for all assignments to p in the CASE, shouldn’t that > catch your case? > Br Jörg > Am 30.10.2020 um 23:05 schrieb Michael Schierl <schierlm at gmx.de>: > > Hello Andreas, > > >> Am 30.10.2020 um 14:05 schrieb Andreas Pirklbauer: >> The official Oberon-07 compiler, as published at www.projectoberon.com, >> contains a serious type loophole in type case statements >> > > [...] > > >> but continues to ALLOW… >> >> 1. Local variables or parameters (value or VAR) parameters as case variables > > I think this can be exploited: > > MODULE TestB; > IMPORT Texts, Oberon; > > TYPE R0 = RECORD END; > R1 = RECORD (R0) fld1: SET END; > R2 = RECORD (R0) fld2: INTEGER END; > P0 = POINTER TO R0; > P1 = POINTER TO R1; > P2 = POINTER TO R2; > > VAR p0: P0; p1: P1; p2: P2; W: Texts.Writer; > > PROCEDURE checkA(VAR p: P0); > BEGIN > CASE p OF P1: > p0 := p2; > p.fld1 := {4,1} > END; > Texts.WriteInt(W, p2.fld2, 4); (*18*) > Texts.Append(Oberon.Log, W.buf) > END checkA; > > PROCEDURE Go*; > BEGIN p0 := p1; checkA(p0) > END Go; > > BEGIN NEW(p1); NEW(p2); Texts.OpenWriter(W) > END TestB. >

1 0

Serious type loophole in type case statements and a possible fix
by Andreas Pirklbauer 30 Oct '20

30 Oct '20

This case below is now also caught by the modified compiler at [*]. A case variable of a type case statement can now only be one of the following: 1. Local variables (pointer or record) 2. Pointer value parameters 3. Record VAR parameters -ap [*] http://github.com/andreaspirklbauer/Oberon-type-case-statement-without-loop… > When the compiler automatically generates a type guard (ORG.TypeTest) > for all assignments to p in the CASE, shouldn’t that > catch your case? > Br Jörg > Am 30.10.2020 um 23:05 schrieb Michael Schierl <schierlm at gmx.de>: > > Hello Andreas, > > >> Am 30.10.2020 um 14:05 schrieb Andreas Pirklbauer: >> The official Oberon-07 compiler, as published at www.projectoberon.com, >> contains a serious type loophole in type case statements >> > > [...] > > >> but continues to ALLOW… >> >> 1. Local variables or parameters (value or VAR) parameters as case variables > > I think this can be exploited: > > MODULE TestB; > IMPORT Texts, Oberon; > > TYPE R0 = RECORD END; > R1 = RECORD (R0) fld1: SET END; > R2 = RECORD (R0) fld2: INTEGER END; > P0 = POINTER TO R0; > P1 = POINTER TO R1; > P2 = POINTER TO R2; > > VAR p0: P0; p1: P1; p2: P2; W: Texts.Writer; > > PROCEDURE checkA(VAR p: P0); > BEGIN > CASE p OF P1: > p0 := p2; > p.fld1 := {4,1} > END; > Texts.WriteInt(W, p2.fld2, 4); (*18*) > Texts.Append(Oberon.Log, W.buf) > END checkA; > > PROCEDURE Go*; > BEGIN p0 := p1; checkA(p0) > END Go; > > BEGIN NEW(p1); NEW(p2); Texts.OpenWriter(W) > END TestB. > > > Using a real (but harmless) type confusion from SET to INTEGER to prove > the point better :-) > > This can obviously can be more convoluted/sophisticated, and I can't > think of an easy way to fix it without disallowing POINTER VAR > parameters altogether. > > > Regards, > > > Michael > --

1 0

Serious type loophole in type case statements and a possible fix
by Andreas Pirklbauer 30 Oct '20

30 Oct '20

The official Oberon-07 compiler, as published at www.projectoberon.com, contains a serious type loophole in type case statements CASE x OF T0:.. | T1:.. END where x is a pointer or record VAR param and T0, T1.. are pointer or record types. For example, the test program Test0 below *compiles* without any error message, but leads to incorrect behaviour at run time. In this particular case, it is because the case variable p0 is a *global* variable with is assigned to a *different* global variable p2 of a *different* extension P2 *within* (!) the case statement. But the CASE statement still thinks p0 is of type P1, not P2... There are other situations, where type errors can occur at runtime. For example, if the case variable which is of a pointer type is passed as a VAR parameter to another procedure, which then modifies its dynamic type through an assignment within the procedure.. I have therefore modified the Oberon-07 compiler (a little tricky, but doable with reasonable effort), such that it.. now DISALLOWS... 1. Global case variables p in a case statement CASE p OF .. END 2. Assignments *to* case variables p *within* (the scope of) a CASE statement 3. Passing a case variable p of type POINTER as a VAR parameter to a procedure P(p) but continues to ALLOW… 1. Local variables or parameters (value or VAR) parameters as case variables 2. Assignments to *fields* v.f of a case variable v (where v can be either a pointer or a record) 3. Passing a case variable v as a *value* parameter to a procedure P(v), (where v can be either a pointer or a record) 4. Passing a case variable r of type RECORD as a VAR parameter to a procedure P(r) (where the r must itself be a VAR parameter) I believe the above restrictions are acceptable. If not, one would have to tinker with the syntax of the type case statement itself. Below is a test program Test1 which - I believe - now produces the correct error messages (shown just below the test program Test1). The question is: ~~~~~~~~~~~~~ Are there any other cases one may need to consider, which could lead to type loop holes? -ap ——————— module Test0 ——————————— MODULE Test0; (* * The following module compiles under the regular Oberon-07 compiler * but has a type loophole at run time *) IMPORT Texts, Oberon; TYPE R0 = RECORD fld0: INTEGER END; R1 = RECORD (R0) fld1: INTEGER END ; R2 = RECORD (R0) fld2: INTEGER END ; (*same field offset as R1.fld1!*) P0 = POINTER TO R0; P1 = POINTER TO R1; P2 = POINTER TO R2; VAR p0: P0; p1: P1; p2: P2; r0: R0; r1: R1; r2: R2; W: Texts.Writer; PROCEDURE AssignGlobal(); BEGIN p0 := p2 END AssignGlobal; PROCEDURE check0(); BEGIN p0 := p1; (*sets the dynamic type of the global variable p0 to P1*) CASE p0 OF P1: AssignGlobal(); (*sets the dynamic type of p0 to P2*) p0.fld1 := 123; (*but the CASE stmt still thinks p0 is of type P1, but writes the data to p2.fld2*) END ; Texts.WriteInt(W, p2.fld2, 4); Texts.Append(Oberon.Log, W.buf) (*123!!*) END check0; PROCEDURE Go*; BEGIN check0() END Go; BEGIN NEW(p0); NEW(p1); NEW(p2); Texts.OpenWriter(W) END Test0. ORP.Compile Test0.Mod/s ~ System.Free Test0 ~ Test0.Go When compiled with the official Oberon-07 compiler, there is no compile-time error, but an incorrect behaviour at run time (see description above) When compiled with the *modified* Oberon-07 compiler, the following error message is produced at compile time: OR Compiler 8.3.2020 / AP 6.8.20 compiling Test0 pos 664 global case variable not allowed compilation FAILED ——————— module Test1 ——————————— MODULE Test1; (* * The error messages below are produced by a modified Oberon-07 compiler * modifies the type case statement (CASE p OF T1... | T2... ) such that it * * Disallows... * * 1. Global case variables p in a case statement CASE p OF .. END * 2. Assignments *to* case variables p *within* (the scope of) a CASE statement * 3. Passing a case variable p of type POINTER as a VAR parameter to a procedure P(p) * * But contines to allow... * * 1. Local variables or parameters (value or VAR) parameters as case variables * 2. Assignments to *fields* p.f of a case variable p (either a pointer or record) * 3. Passing a case variable p as a *value* parameter to a procedure P(p) * 4. Passing a case variable r of type RECORD as a VAR parameter to a procedure P(r) * (note: the record r must itself be a VAR parameter in this case) *) TYPE R0 = RECORD fld0: INTEGER END; R1 = RECORD (R0) fld1: INTEGER END ; R2 = RECORD (R0) fld2: INTEGER END ; (*same field offset as R1.fld1!*) P0 = POINTER TO R0; P1 = POINTER TO R1; P2 = POINTER TO R2; VAR p0: P0; p1: P1; p2: P2; r0: R0; r1: R1; r2: R2; PROCEDURE AssignGlobal(); BEGIN p0 := p2 END AssignGlobal; PROCEDURE Proc1(p0: P0); BEGIN END Proc1; PROCEDURE Proc2(VAR p1: P1); BEGIN END Proc2; PROCEDURE Proc3(VAR r0: R0); BEGIN r0 := r2 END Proc3; (*projection*) PROCEDURE Proc4(VAR i: INTEGER); BEGIN END Proc4; PROCEDURE Proc5(b: BOOLEAN); BEGIN END Proc5; PROCEDURE check0(); BEGIN p0 := p1; (*sets the dynamic type of the global variable p0 to P1*) CASE p0 OF (*ERROR "global case variable not allowed"*) P1: AssignGlobal(); (*if p were allowed to be global, the dynamic type of p0 would be set to P2 here*) p0.fld1 := 123 (*and therefore, there would be a type violation here, as the CASE stmt thinks p0 is still of type P1*) END ; END check0; PROCEDURE check1(); VAR p, pa: P0; BEGIN p := p1; (*sets the dynamic type of the local variable p to P1*) CASE p OF P1: pa := p; (*allowed, since p is not modified*) Proc1(p); (*allowed, since p is passed as a value parameter*) Proc2(p); (*ERROR "read-only" -> not allowed, since p is passed as a VAR parameter*) Proc4(p.fld1); (*allowed, since a field of p, but not p itself is passed*) p := p2; (*ERROR "assignment not allowed" -> not allowed, since p is modified through an assignment*) p.fld1 := 123; (*guaranteed to be correct, since the runtime type of p cannot change inside CASE*) CASE pa OF (*nested case statement*) P1: Proc1(p); (*allowed, since p is passed as a value parameter*) Proc2(p) (*ERROR "read-only" -> not allowed, since p is passed as a VAR parameter*) END ; p := p1 (*ERROR "assignment not allowed" -> not allowed, since p is modified through an assignment*) END END check1; PROCEDURE check2(); BEGIN p0 := p1; (*sets the dynamic type of the global variable p0 to P1*) IF p0 IS P1 THEN AssignGlobal(); (*the runtime type of p0 is not P1 anymore, but P2*) p0(P1).fld1 := 123; (*thereore, there (correctly) is a type guard failure (TRAP 2) at runtime*) END END check2; PROCEDURE check3(VAR r: R0); VAR rr: R1; BEGIN r := r1; (*allowed since pr is a VAR parameter (projection to fields of base type)*) CASE r OF R1: rr := r; (*allowed, since r itself is not modified*) r := r1; (*ERROR "assignment not allowed" -> not allowed, since r is modified through an assignment*) Proc3(r); (*allowed since r is a record passed as a VAR parameter*) r.fld1 := 234 END END check3; PROCEDURE check4(); VAR r: R1; BEGIN r := r1; CASE r OF (*ERROR "invalid type" -> not allowed since r is neither a pointer nor a VAR parameter*) R1: r.fld1 := 345 END ; END check4; PROCEDURE check5(p: P0); BEGIN CASE p OF P1: Proc5(p IS P1) END END check5; PROCEDURE Go*; BEGIN check0(); check1(); check2(); check3(r0); check4(); check5(p0) END Go; BEGIN NEW(p0); NEW(p1); NEW(p2) END Test1. ORP.Compile Test1.Mod/s ~ # compiled with MODIFIED compiler OR Compiler 8.3.2020 / AP 6.8.20 compiling Test1 pos 1679 global case variable not allowed pos 2284 read-only pos 2456 assignment not allowed pos 2814 read-only pos 2916 assignment not allowed pos 3613 assignment not allowed pos 3910 invalid type pos 4011 not a constant compilation FAILED

5 6

Serious type loophole in type case statements and a possible fix
by Andreas Pirklbauer 30 Oct '20

30 Oct '20

> It feels like they are not in the spirit of Oberon… > all because of fear of missing out on performance? For those who want to run some before/after performance comparisons - I’d be interested in hearing about the results - here is one possible implementation of the modified type case statement which eliminates all loopholes: http://github.com/andreaspirklbauer/Oberon-type-case-statement-without-loop… (to see what has changed relative to PO2013, do a diff between the first 2 commits) Implementation cost: ~15 lines (relative to PO2013)

1 0

Serious type loophole in type case statements and a possible fix
by Andreas Pirklbauer 30 Oct '20

30 Oct '20

> I remember reading about a similar issue related to the WITH statement of > Oberon-90, so the way I solved this problem in oberonc is to add an additional > type test each time the case variable is referred in the statements of a particular case label. Hi Luca, Yes, that’s of course the obvious solution. But that would re-introduce run-time overhead that the type case statement avoided in the first place. In that case, one might as well get rid of the CASE altogether and just use IF p IS T THEN instead: i.e. replace... PROCEDURE check0(); BEGIN p0 := p1; CASE p0 OF P1: AssignGlobal(); p0*(P1)*.fld1 := 123; END END check0; with... PROCEDURE check0(); BEGIN p0 := p1; IF p0 IS P1 THEN AssignGlobal(); p0*(P1)*.fld1 := 123; END END check0; My (proposed) solution rescues the CASE statement (which is efficient relative to IF x IS T + series of additional type tests inside the IF statement), while at the same time solving its type loophole issues. But I would not mind eliminating the type case statement and just have type guards. -ap

3 2