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

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

Re (2): Names and genealogies.
by peter＠easthope.ca 21 Oct '20

21 Oct '20

From: Joerg <joerg.straube(a)iaeth.ch> Date: Mon, 22 Jun 2020 22:48:04 +0300 > So just forget S3, System3 and other names you might have come along OK, thanks Joerg. in the front page, https://en.wikibooks.org/wiki/Oberon , I've made the changes "S3" => "ETH Oberon". The former page https://en.wikibooks.org/wiki/Oberon/S3 is now https://en.wikibooks.org/wiki/Oberon/ETH_Oberon . Sub-pages also renamed accordingly. The change is also done in https://en.wikibooks.org/wiki/Oberon/sitemap . Several red links remain there until I can salvage the pages. Meanwhile, most can be reached via the WayBack link in the green box. I have not proof read yet and am unlikely to have much time before winter weather returns. Will try to correct any erros reported. Regards, ... P. -- https://en.wikibooks.org/wiki/Medical_Machines https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140 Bcc: peter at easthope. ca

3 2

PO2013 - Colour Ergonomy
by Tomas Kral 30 Jun '20

30 Jun '20

Hi, I was toying with colours on FPGA board lately. In your experience, what colour combination (dirt & backdrop) causing least eye fatigue? I realised it may even vary for day light, or night (being night owls like me). I know, PO2013 specifies SW[7] that does screen invert. FPGA RGB tends to have brightish colours, it may well boil down to ones monitor settings. Or even if its CRT, or modern LED. -- Tomas Kral <thomas.kral(a)email.cz>

2 5

Oberon Compiler Optimization (was: Oberon-07 - SYSTEM.MSET)
by Chris Burrows 26 Jun '20

26 Jun '20

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of John > R. Strohm > Sent: Friday, 26 June 2020 11:45 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Oberon-07 - SYSTEM.MSET > > > --- chris(a)cfbsoftware.com wrote: > > > > > -----Original Message----- > > > From: Tomas Kral [mailto:thomas.kral@email.cz] > > > Sent: Friday, 26 June 2020 4:51 PM > > > To: oberon(a)lists.inf.ethz.ch > > > Cc: chris(a)cfbsoftware.com > > > Subject: Re: [Oberon] Oberon-07 - SYSTEM.MSET > > > > > > > Using the auto-increment extension to SYSTEM.PUT > > > > > > Interesting, PUT(VAR addr...), addr passed by reference? > > > > > > > Yes - there are two different signatures: > > > > PROCEDURE PUT*(address: INTEGER; x: <any basic type>); > > > > PROCEDURE PUT*(VAR address: INTEGER; x: <any basic type>; inc: > > INTEGER); > > The original code fragment was (approximately) > > REPEAT SYSTEM.PUT(addr, value, incr) UNTIL addr > limit; > > This is logically equivalent to > > REPEAT > BEGIN > SYSTEM.PUT(addr, value); > addr := addr + incr; > END > UNTIL addr > limit; > > I am admittedly not up on typical Oberon compiler optimization, but I > would generally expect a compiler smart enough to inline the SYSTEM.PUT() > call, in either case, to be able to optimize in the autoincrement as > well. > Optimizations in Oberon compilers tend to be confined to single statements. The compiler is not particularly aware that the increment statement in your example above is associated with the PUT. If instead of addr := addr + incr; you wrote INC(addr, incr); The latter statement is potentially easier to optimise because you are telling the compiler that the source and destination variables are the same, but it still has no effect on any statements preceding or following it. Having said that, I don't believe the INC statement is optimised in the current Oberon compilers. RISC5 in particular does not have an auto-increment instruction that could be useful in this case. If you are interested in the reasoning behind the optimization strategy used in Wirth's Oberon compilers, refer to Section 22. "Leaf procedures and Register Variables" and Section 26.8. "Optimizations" in "An Oberon Compiler for the ARM Processor", Niklaus Wirth 2008: https://inf.ethz.ch/personal/wirth/Oberon/Oberon.ARM.Compiler.pdf Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5

1 0

PO2013 - Simple Arc
by Tomas Kral 26 Jun '20

26 Jun '20

Hi, Just revising `Arc' procedure in simple graph, I have coded this. In fact it just draws quarter circle, based on +/- hint, not sure if good idea. I do not need exact RAD segments, that would probably require Math trigo, but wish to somehow get it better if possible. PROCEDURE Arc*(col, x0, y0, r, mode: INTEGER); VAR x, y, sx, sy, u: INTEGER; BEGIN u := 1 - r; x := r; y := 0; sx := 1; sy := 1; IF x0 < 0 THEN sx := -1 END ; x0 := ABS(x0); IF y0 < 0 THEN sy := -1 END ; y0 := ABS(y0); WHILE y <= x DO IF (sx > 0) & (sy > 0) THEN Dot(col, x0+x, y0+y, mode); Dot(col, x0+y, y0+x, mode) ELSIF (sx < 0) & (sy > 0) THEN Dot(col, x0-y, y0+x, mode); Dot(col, x0-x, y0+y, mode) ELSIF (sx < 0) & (sy < 0) THEN Dot(col, x0-x, y0-y, mode); Dot(col, x0-y, y0-x, mode) ELSE (*(sx > 0) & (sy < 0)*) Dot(col, x0+y, y0-x, mode); Dot(col, x0+x, y0-y, mode) END ; IF u < 0 THEN INC(u, 2*y+3) ELSE INC(u, 2*(y-x)+5); DEC(x) END ; INC(y) END END Arc; -- Tomas Kral <thomas.kral(a)email.cz>

2 2

Re: [Oberon] Oberon-07 - SYSTEM.MSET
by John R. Strohm 26 Jun '20

26 Jun '20

> --- chris(a)cfbsoftware.com wrote: > > > -----Original Message----- > > From: Tomas Kral [mailto:thomas.kral@email.cz] > > Sent: Friday, 26 June 2020 4:51 PM > > To: oberon(a)lists.inf.ethz.ch > > Cc: chris(a)cfbsoftware.com > > Subject: Re: [Oberon] Oberon-07 - SYSTEM.MSET > > > > > Using the auto-increment extension to SYSTEM.PUT > > > > Interesting, PUT(VAR addr...), addr passed by reference? > > > > Yes - there are two different signatures: > > PROCEDURE PUT*(address: INTEGER; x: <any basic type>); > > PROCEDURE PUT*(VAR address: INTEGER; x: <any basic type>; inc: INTEGER); The original code fragment was (approximately) REPEAT SYSTEM.PUT(addr, value, incr) UNTIL addr > limit; This is logically equivalent to REPEAT BEGIN SYSTEM.PUT(addr, value); addr := addr + incr; END UNTIL addr > limit; I am admittedly not up on typical Oberon compiler optimization, but I would generally expect a compiler smart enough to inline the SYSTEM.PUT() call, in either case, to be able to optimize in the autoincrement as well. And, if I was doing the above a lot, I would want a SYSTEM.MEMSET() that expanded inline. --John R. Strohm

1 0

PO2013 - Last sector allocated
by Andreas Pirklbauer 26 Jun '20

26 Jun '20

How about just maintaining a global read-only variable Kernel.LastSector maintained only by Kernel?

2 1

PO2013 - Last sector allocated
by Tomas Kral 26 Jun '20

26 Jun '20

Hi, It has sounded here earlier, it might be sometimes useful, to know last sector used by OBERON.FS. Could this hint where the sector lies? PROCEDURE LastSec(name: FileDir.FileName; sec : INTEGER; VAR cont: BOOLEAN); BEGIN IF sec > lsec THEN lsec := sec END ; cont := TRUE END LastSec; PROCEDURE Last*; BEGIN lsec := 0; FileDir.Enumerate("", LastSec); Texts.WriteInt(W, lsec, 6); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END Last; -- Tomas Kral <thomas.kral(a)email.cz>

4 5

Re: [Oberon] Oberon-07 - SYSTEM.MSET
by John R. Strohm 26 Jun '20

26 Jun '20

> --- joerg.straube(a)iaeth.ch wrote: > In my point of view it’s not worth the effort as eg > > SYSTEM.PUT(Display.Base, 0BABEFACEH); > SYSTEM.COPY( > Display.Base, Display.Base+4, 24575 > ); > > fills the b/w screen with an arbitrary word. Arguably, this should be undefined behavior. SYSTEM.COPY() should ideally be defined to be unpredictable if the blocks overlap, to allow an implementation to run the loop "backwards", if that would yield better performance on that particular system. I do not recall offhand whether SYSTEM.PUT() is expected to expand inline, or do a subroutine call. If the latter, it would make sense to provide a SYSTEM.MEMSET(). --John R. Strohm

3 3

Oberon-07 - SYSTEM.MSET
by Tomas Kral 25 Jun '20

25 Jun '20

Hi, Just thinking, as part of en exercise, we could enrich pseudo module SYSTEM. We have COPY command, we could add a complementing MSET, filling a memory block with arbitrary word. Similarly we have memset(), memcpy() on linux, and I have seen lately a habit in mimicking some ux* commands in Oberon :-) SYSTEM.MSET (choosing other name not to imply Oberon SET{}) Can it be useful in some low level programming, I know NEW() fills block with NIL (0), but sometimes we need -1, or even other? Everything is word aligned and padded by compiler, so MSET could go by words. Bad idea? -- Tomas Kral <thomas.kral(a)email.cz>

2 2