September 2017 - Oberon - mailman3.inf.ethz.ch

FPGA - Screen.Mod
by Tomas Kral 26 Oct '18

26 Oct '18

Hi, EDIT (1) I am looking for `Screen.Mod' module (mainly its `Screen.Grub' command) hinted in PO2013 pictures. I have completed early version of `Bitmaps.Mod' supporting basic set of raster operations. I wish to share pictures and code. As we may not post attachments to the forum, I could expose to GitHub, there is also `WikiBook' run by Lyall E. Please advise. Many thanks. -- Tomas Kral <thomas.kral(a)email.cz>

4 15

FPGA Oberon - Definition Module Tool
by thomas.kral＠email.cz 08 Oct '18

08 Oct '18

Hi, I am thinking of a simple tool that could extract definition info from *.Mod and produce respective *.Def file. Definition files can be quickly looked at, to remind a programmer of the interface *.Mod modules export. While on Linux one could use grep $ grep PROCEDURE\ * *.Mod.txt to obtain info at least about procedures, but how about exported types and variables? I am looking for a recommended way how to simply code such a tool, is it a good idea to use `ORP' parser somehow for the task? I prefer to code it simple, does not have to be perfect, but should carry the idea. Tomas

5 11

FPGA - Bit reversal
by Tomas Kral 06 Oct '17

06 Oct '17

Hi, I have been toying with bit reversals for byte and word types. Simple forms consist of plain shifting in sets of bits. PROCEDURE ReverseByte(wd: INTEGER): INTEGER; VAR i: INTEGER; rbt, t, u: SET; BEGIN u := SYSTEM.VAL(SET, wd); rbt := {}; FOR i := 0 TO 7 DO t := ASR(u, i)*{0}; t := LSL(t, 7-i); rbt := rbt+t; END RETURN SYSTEM.VAL(INTEGER, rbt) END ReverseByte; (* inefficient, how to improve? *) PROCEDURE ReverseWord(wd: INTEGER): INTEGER; VAR i: INTEGER; rwd, t, u: SET; BEGIN u := SYSTEM.VAL(SET, wd); rwd := {}; FOR i := 0 TO 31 DO t := ASR(u, i)*{0}; t := LSL(t, 31-i); rwd := rwd+t; END RETURN SYSTEM.VAL(INTEGER, rwd) END ReverseWord; More efficiency comes with some complication. Found this at StackOverflow. unsigned char reverse(unsigned char b) { b = (b & 0xF0) >> 4 | (b & 0x0F) << 4; b = (b & 0xCC) >> 2 | (b & 0x33) << 2; b = (b & 0xAA) >> 1 | (b & 0x55) << 1; return b; } The below procedure prints byte/word in binary, seeing long strings of '1' and '0' for words, makes me think if BYTE type should not be favoured more to INTEGER on FPGA? (* write word [wd] in binary, n=[1..32] number of bits to print *) PROCEDURE WriteBin(wd, n: INTEGER); VAR i: INTEGER; ch: CHAR; t: SET; BEGIN FOR i := 0 TO n-1 DO t := SYSTEM.VAL(SET, ASR(wd, i))*{0}; ch := CHR(SYSTEM.VAL(BYTE, t)+ORD("0")); Texts.Write(W, ch) END; Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END WriteBin; -- Tomas Kral <thomas.kral(a)email.cz>

6 25

Re: [Oberon] Oberon Digest, Vol 160, Issue 21
by Søren Renner 05 Oct '17

05 Oct '17

Also, AOS and Oberon will become much more widely noticed as soon as my raytracing research receives the attention and praise that it deserves. On Thu, Sep 28, 2017 at 6:00 AM, <oberon-request(a)lists.inf.ethz.ch> wrote: > Send Oberon mailing list submissions to > oberon(a)lists.inf.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.inf.ethz.ch/mailman/listinfo/oberon > or, via email, send a message with subject or body 'help' to > oberon-request(a)lists.inf.ethz.ch > > You can reach the person managing the list at > oberon-owner(a)lists.inf.ethz.ch > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Oberon digest..." > > > Today's Topics: > > 1. Re: General - Academic vs Commercial applications > (Felix Friedrich) > 2. Re: General - Xerox PARC 1970 (Tomas Kral) > 3. Re (2): General - Academic vs Commercial applications > (peter(a)easthope.ca) > 4. NativeOberon's FileName limitations - HOW2 extend? (eas lab) > 5. Re: General - Academic vs Commercial applications (eas lab) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Sep 2017 12:17:23 +0200 > From: Felix Friedrich <felix.friedrich(a)inf.ethz.ch> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] General - Academic vs Commercial applications > Message-ID: <d04806c6-955e-fa5d-d726-09ba6622c2c5(a)inf.ethz.ch> > Content-Type: text/plain; charset="utf-8"; format=flowed > > In fact Oberon is still taught at ETH Zurich. > > We are giving a course on System Construction and discuss some Oberon > language dialects, Oberon inspired operating or runtime systems and > programmable hardware supporting or based on Oberon related languages > and systems. In more detail we teach > > (a) The Minos Runtime System (based on HeliOS, system control for > unmanned helicopters), programmed in a dialect of Oberon07 [FF] > (b) The A2 runtime system and GUI together with Active Oberon [FF] > (c) Oberon running on FPGAs: the RISC processor [Paul Reed] > (d) Systems on a Chip, FPGA and Hybrid Systems, programmed using Active > Cells, another dialect of Oberon [FF] > > cf. http://lec.inf.ethz.ch/syscon/2017/ > > Without exaggeration and with a little bit of pride I can say that > students like this course a lot -- because we really show how these > systems work behind the scenes over all levels. We (Paul and I) can say > that we understand every single bit of it and bring this accross as a > strong argument for simplicity. > > Apart from that I am the "last man standing" for Oberon at ETH. I have a > lecturer position at ETH and am giving large computer science service > courses at ETH (hundred of students, C++, Java or whatever is > requested), which limits my time for working with and for Oberon. I love > to play around with the language, compiler and runtime systems and > optimize them according to what I, personally, find the most optimal way > to present or use the langauge. Because much is driven by personal > taste, I hesitate to sell my own ideas as "the truth", while I have some > strong opinions. I feel responsible for the A2 repository comprising the > A2 Multicore OS, its graphical user Interface and the FoxCompiler > toolchain. > > I should not forget to mention that the dialects of Oberon and the > systems that we teach are in use in real-world commercial systems sold > by companies that in fact use Oberon for commercial development. For our > course this is a very important argument underpinning that following the > principle of simplicity can have very positive practical impact, even if > it is hard to sell academically. > > Kind regards > Felix Friedrich > > > > > > On Tue, 26 Sep 2017 10:36:35 +0000 > > Treutwein Bernhard <Bernhard.Treutwein(a)Verwaltung.Uni-Muenchen.DE> > > wrote: > > > >> yes, afaik, with the retirement of J?rg Gutknecht the "Native Systems > >> Group" was shut down. > > Having said that, Oberon is no longer taught, developed, and included > > in informatics research sylabus, at ETH University? > > > > So is AOS dropped as well? > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 27 Sep 2017 12:49:38 +0200 > From: Tomas Kral <thomas.kral(a)email.cz> > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] General - Xerox PARC 1970 > Message-ID: <20170927124938.6c945698@raspberrypi> > Content-Type: text/plain; charset=UTF-8 > > On Sun, 24 Sep 2017 03:30:24 -0700 > Douglas G Danforth <danforth(a)greenwoodfarm.com> wrote: > > > She showed me the Alto when I visited PARC.? Its hard drive was a > > large platter which, iirc, held only of data. > > 14MB given the enthropy of information may seem like today's 14GB, as I > see similar stuff on Alto's screen as on mobile displays, say from > a higher level of perspective, so to speak. That is 1970. > > I remember a decade after (1982 ZX/ATARI, etc), popular 8-bit home > computing, 64K of RAM was unheard of limit, possible only in mainframes > before. > > Then `1984' - Orwell's Big Brother was chosen as the main theme of > Apple's marketing campaign, for their computer released 1984. > > Workstation's like Alto, were a dream, also the price $40.000, > something like that. Which was not a market price just the cost of > development, probably? > > I am lead to believe, that what maters is relative performance. > > Between various releases of today's user s/w, I usually notice, slower, > more complicated and requiring faster h/w, but that could well be my > paranoia as I get older :-) > > -- > Tomas Kral <thomas.kral(a)email.cz> > > > ------------------------------ > > Message: 3 > Date: Wed, 27 Sep 2017 09:58:27 -0700 > From: peter(a)easthope.ca > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Re (2): General - Academic vs Commercial > applications > Message-ID: <E1dxFfH-0000rF-Hc(a)xo-53-1d-bb.localdomain> > > Felix, > > Thanks for your overview. > > From: Felix Friedrich <felix.friedrich(a)inf.ethz.ch> > Date: Wed, 27 Sep 2017 12:17:23 +0200 > > Apart from that I am the "last man standing" for Oberon at ETH. > > One is better than zero. Thanks for your dedication! This > circumstance is a good argument for incuding the language report for > Active Oberon as HTML in the wikibook. Being a wiki, anyone can work > on it. Subject to your permission of course. > > Incidentally, accesses to the front page has settled to 400-500/month. > https://en.wikibooks.org/w/index.php?title=Oberon&action=info > Certain to climb as the content increases and improves. > > Regards, ... Lyall E. > -- > > 123456789 123456789 123456789 123456789 123456789 123456789 123456789 > Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 > http://easthope.ca/Peter.html Bcc: peter at easthope. ca > > > > ------------------------------ > > Message: 4 > Date: Wed, 27 Sep 2017 17:09:16 +0000 > From: eas lab <lab.eas(a)gmail.com> > To: <oberon(a)inf.ethz.ch> > Subject: [Oberon] NativeOberon's FileName limitations - HOW2 extend? > Message-ID: > <CAN3-DLH2igPv3gRQFWk8CCPh_frLdqLEpode9r-5sFjCYJ67Pg@ > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Linux : X11 is a monster, but LNO [121104] runs in a FrameBuffer nicely; > also under 64bit. > Why would you NEED LNO ? > 1. to have multiple files visible together on the same screen; > 2. with powerfull mouse-chording ability; > PublicDomain wily [needs X11], copied from ETHO, is even better, except > lacks > 3. ETHO's coloring capability: to give an extra dimension to > complex relationships between texts, possibly in multiple files. > > Mildly complex tasks, soon need 4, 5, 6 ...TextFrames viewable-together. > Since screen-area is the limiting factor, M$'s wastefull <staggered > frames>, > copied by Aos, is NOT acceptable. The paper-book, where each of hundreds > of pages "automatically line-up", is a magical concept! > > The big problem/weakness of LNO: not being able to immediately read/write > to files anywhere in the file-tree, can be reduced by: > 1. use a convenient file-navigator, like mc, which allows to > 2. <push a button> at the reqired-file, which stores its /PATH/Name to a > fixed location, which > 3. is accessed by LNO to mount the file-to-be-accessed by LNO. > > Right now, while composing this text, via USBstik:Linux:TinyCore46:LNO > I want to access some Oberon:V4 files on the M$-partition. > I failed: apparently LNO can't mount FATFS, like LEO can. > It shouldn't be difficult to extend the capability? > > But read/write to V4 files in LinuxFS, is OK via: > FileSystem.Mount V4 LinuxFS /mnt/sdb2/CRG/ETHO/V4dirTree/ > usr/local/oberon/Text/~ > > The 4-string command/M.P had the last/long string stored in the known > location; > so "V4" is my chosen name and string1, string3 are in the <Tools Text>; > and the user need only add his chosen name to make the 4-string command. > Then System.Directory ^ V4:* lists the directory contents; giving > immediate > access to the 96 files:----------- > V4:. > V4:.. > V4:Analyzer.Tool > V4:AsciiCoder.Tool > V4:Backup.Tool > V4:Balloon.Text > V4:BalloonIdx.hlp > ... > V4:Find.Tool > > V4:Welcome.Text > V4:Xref.Tool > > 96 files ---------------- > LNO can access all: Aos, *nix, FATFS and presumably V4 formats. > The PROBLEM remains, to access eg. "tmp:mc-root", where "mc-root" > is not a valid <FileName>. > AFAIR <Linux ETH Oberon> was able to access such filenames by quoting? > Can we extend LNO, perhaps based on LEO? > > == Chris Glur. > > PS. The fact that ETHO's System.Directory output is not available: > ordered by recentcy, is a serious deficiency: not acknowledging that > <the stack and tree> are central to cognition & thus computing ? > > > ------------------------------ > > Message: 5 > Date: Thu, 28 Sep 2017 01:51:22 +0000 > From: eas lab <lab.eas(a)gmail.com> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] General - Academic vs Commercial applications > Message-ID: > <CAN3-DLGTDX=a5fnxA7=w54ZsMjzh6ZY4Y22xMtga2OtrJ++Oww@mail. > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Looks like a brilliant syllabus: teaching universal 1st-principles, > and not just the current FB, twitter fads. > > When RPi first came out, I wanted to build a P-code interpreter, > as I had done in the 70s for Fairchild-F8, 63xx/68xx, Intel16bit; > but I couldn't see how to <single step design asm-instructions> > [as I had always done - I coded the F8 via a teletype in *HEX*] > since appaently the ARM assembler takes the user's <intentions> > and OPTIMISES it, in the background, to generate the actual. > single-instructions. > > No one on the RPi NNTP could understand my query, because today > it's always "doA, doB...", without understanding the underlying > principles. But now, I see the critical reference to "OPTIMIZED" in > http://lec.inf.ethz.ch/syscon/2017/slides/LSC17Slides0926.pdf > > == Chris Glur. > > > ------------------------------ > > Subject: Digest Footer > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > ------------------------------ > > End of Oberon Digest, Vol 160, Issue 21 > *************************************** >

7 10

OP2 Oberon-07 Compiler
by Peter Matthias 02 Oct '17

02 Oct '17

With the discussion Oberon-2 vs. Oberon-07, there comes into my mind that an Oberon-07 front end for OP2 compiler would be nice. I am currently only interested in back ends, but if anyone changes the front end to accept 07 syntax, I would change the back ends (ARM32, MIPS32, RISC-V, more likely to come) to support it. Peter

2 1

Procedure variables and local procedures
by Andreas Pirklbauer 01 Oct '17

01 Oct '17

> From: Skulski, Wojciech skulski(a)pas.rochester.edu Fri Sep 29 14:34:06 CEST 2017 > What happens when the enclosing procedure GlobalProc declares its local variables, which are then used within its local procedure? > Local variables are allocated on the stack. Does the "counter" exist when the procedure IncCounter is called by a client module? > Wojtek > MODULE M; > TYPE Proc* = PROCEDURE; > VAR GlobalProc*: Proc; (*exported*) > LocalProc: Proc; (*not exported*) > > PROCEDURE GlobalProc2; > VAR LocalVar2: Proc; > counter: INTEGER; (*allocated on the stack*) > PROCEDURE ZeroCounter; BEGIN counter := 0 END ZeroCounter; > PROCEDURE IncCounter; BEGIN counter := counter + 1 END IncCounter; > BEGIN (*GlobalProc2*) > GlobalProc := IncCounter; (*allowed (LocalProc2 visible in current scope)*) > LocalProc := ZeroCounter; (*allowed (LocalProc2 visible in current scope)*) > END GlobalProc2; > > BEGIN (*M*) > GlobalProc2(); (*assign the variables*) > ZeroCounter (); (*calling proc local to the module via proc variable*) > (*IncCounter can now be called by clients. Can it be really?*) > END M. Wojtek, your (modified) module M will not compile when compiled with an Oberon-07 compiler, but return a “level error, not accessible” error message. The reason is that access to intermediate variables is no longer allowed in Oberon-07 (it was in the original version of the Oberon language published in 1988, but it no longer is). This means that a local procedure (as your procedure ZeroCounter) can only modify *strictly* local variables (i.e. declared local to ZeroCounter) or *strictly* global variables (i.e. declared as global variables in module M), but nothing in between. Therefore, modifying the variable “counter” (which is declared local to GlobalProc2, i.e. at an intermediate level) from within the local procedure ZeroCounter is not permitted in Oberon-07. Hence the error message. And this is precisely the one change in the language that was necessary to make my original version of module M work. It’s that the language itself has changed with Oberon-07 around 2007, and for good reasons. For some additional insight into this decision, see ch. 12.2. on p.73 of https://www.inf.ethz.ch/personal/wirth/CompilerConstruction/CompilerConstru… <https://www.inf.ethz.ch/personal/wirth/CompilerConstruction/CompilerConstru…> ("In fact, programming experience has shown that the access of intermediate level variables is bad practice and better be avoided. Implementers must welcome this insight, as it makes the static link superfluous.”) Andreas

9 30

Re: [Oberon] Oberon Digest, Vol 160, Issue 26
by Michael McGaw 30 Sep '17

30 Sep '17

I have found this thread of discussion to be immensely interesting, as I use Oberon to do embedded work for much of what I do. I have focused on the well sorted OP2 compiler for much of this, and also use M2 (programmed in an Oberon-like subset) for many things. The changes being discussed (and those that have already been made) in PO, or 07 (e.g., any follow-on dialect to Oberon that is post OP-2 in this millennium) are in many cases welcome, as they clarify and simplify. But they do confound. The confound our previous thinking and experience in language use (remember, there are practitioners lurking in this list who rely on a high degree of familiarity and experience with a given language definition and its implementation to ensure reliable work products). But perhaps most importantly, the changes are most dramatic in their impact on code bases. Many of the changes made in PO/07 are of the type that cannot be machine translated, in the sense of a source to source translator. They require the practitioner to perform code redesign in order to adopt the latest compilers. LOOP, RETURN fall into this category. The local procedure situation is another. Then, there are the many more minor, but tedious to adopt changes of bit op functions and their names, and the like. To adopt these later variants in Oberon is quite a task, if you must convert an existing, active code base to adopt the new language. And, this base works only until the *next* decision to simplify or streamline the language further. Another reason I like OP2: it is more than capable, but more than this, it is static in its definition and predictable in its behavior. I can depend on what it does, and how it does it. Moreover, I can enforce that the compiler DOES NOT change, and avoid a compiler manufacturer's next release of its tool set, and the problems THAT engenders. This reason alone is enough to adopt (one of) the Oberon dialects being discussed in this list, and locking in on it. I am not exercising a right of contrarianism, here; rather, I do very much appreciate the laser-like intensity and clarity with which Wirth has gone after these many details. It certainly makes the teaching of language design and implementation much more focused and on point. But practitioners, who build code bases and who must maintain the painfully worked-out, stable behaviors of these code bases most certainly DO NOT want to have to open them back up, and redesign (and then, worst of all, retest and confirm, on all platforms, in all environments, that the changes are stable and correct), with no other benefit than language compatibility. In other words, to be compelled to have to do work that adds no value to the functional performance of this code base. This is the bane of those who operate in the commercial realm. It is the main reason I maintain a close eye on these subsequent language developments, but also why I am extremely careful in committing a new project to these developments. -M On Saturday, September 30, 2017 6:00 AM, "oberon-request(a)lists.inf.ethz.ch" <oberon-request(a)lists.inf.ethz.ch> wrote: Send Oberon mailing list submissions to oberon(a)lists.inf.ethz.ch To subscribe or unsubscribe via the World Wide Web, visit https://lists.inf.ethz.ch/mailman/listinfo/oberon or, via email, send a message with subject or body 'help' to oberon-request(a)lists.inf.ethz.ch You can reach the person managing the list at oberon-owner(a)lists.inf.ethz.ch When replying, please edit your Subject line so it is more specific than "Re: Contents of Oberon digest..." Today's Topics: 1. Re: Procedure variables and local procedures (Skulski, Wojciech) 2. Re: Procedure variables and local procedures (Chris Burrows) 3. Re: Procedure variables and local procedures (Chris Burrows) 4. Re: Procedure variables and local procedures (Skulski, Wojciech) 5. Re: Procedure variables and local procedures (Skulski, Wojciech) 6. Re: Procedure variables and local procedures (J?rg) 7. Re: Procedure variables and local procedures (chris) ---------------------------------------------------------------------- Message: 1 Date: Sat, 30 Sep 2017 01:18:50 +0000 From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Procedure variables and local procedures Message-ID: <DM5PR0701MB3672FBF0990DD0769421BE0FFF7F0(a)DM5PR0701MB3672.namprd07.prod.outlook.com> Content-Type: text/plain; charset="Windows-1252" Joerg: >Btw. another issue I see with Oberon-07 ist the removal of dynamic > arrays. I cannot imagine how to write for example a string library or > something like that without. I do not know the string libs mentioned by Chris, but I used mathematical libs by Robert Campbell. I also wrote waveform data acquisition and corresponding graphics. All of these highly useful programs are based on something like the following, copied from my own code. RArray* = POINTER TO ARRAY OF REAL; IArray* = POINTER TO ARRAY OF INTEGER; > Would you please explain ?dynamic arrays?? Do you miss the low level SYSTEM.NEW(p, n)? I am guessing that Chris has the above in mind. I second his opinion: without the dynamic arrays (or "open arrays") the language is crippled. > The modules handling dynamic structures (eg. text editor, network stack or files) > do in principle use the same internal scheme: they use chains of blocks of fixed size. Perhaps it works OK if one is developing a text editor. I still remember Turbo Editor Toolbox was using a similar approach. Writing an algebra library using this method takes us back to FORTRAN. Here I second Chris. I too cannot imagine working in this area without dynamic arrays. Perhaps you guys could have a look at monumental work done by Robert? This might provide some arguments against cutting off what you consider dead wood, which is in fact crucial for some applications. Thanks, Wojtek ------------------------------ Message: 2 Date: Sat, 30 Sep 2017 11:55:56 +0930 From: "Chris Burrows" <chris(a)cfbsoftware.com> To: "'ETH Oberon and related systems'" <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Procedure variables and local procedures Message-ID: <001801d33993$731ca830$5955f890$(a)cfbsoftware.com> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > chris > Sent: Saturday, 30 September 2017 4:21 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Procedure variables and local procedures > > > Very terse. How does it work in the reverse case. > > VAR b : BYTE; i : INTEGER; > i := 1000; b := i; > > Does it trap for overflow? > chris, The details of runtime traps are implementation-specific questions and do not form part of the language design. Runtime overflows (INTEGER as well as BYTE) are not trapped in Project Oberon or Astrobe Oberon. In fact the Random function exploits this behaviour and would break if ported to a system that didn't allow you to turn off overflow trapping. If you have no control over the values of the data that reach that point in your code and you want to trap them (a more subtle scenario than your example) you should write: ASSERT(i <= 255); b := i; Chris (Burrows, that is - I'm not talking to myself ;-)) CFB Software http://www.astrobe.com/RISC5 ------------------------------ Message: 3 Date: Sat, 30 Sep 2017 12:12:52 +0930 From: "Chris Burrows" <chris(a)cfbsoftware.com> To: "'ETH Oberon and related systems'" <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Procedure variables and local procedures Message-ID: <001901d33995$d2dff7c0$789fe740$(a)cfbsoftware.com> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Skulski, Wojciech > Sent: Saturday, 30 September 2017 10:49 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Procedure variables and local procedures > > Perhaps you guys could have a look at monumental work done by Robert? > This might provide some arguments against cutting off what you > consider dead wood, which is in fact crucial for some applications. > I would not dream of using a hammer to drive in a fence post any more than I would choose a sledgehammer to drive in a nail. Similarly, computer languages are just tools - no one tool is suitable for all jobs. The more you try to make one toll suitable for a different job the less suitable it is for use with the job is was designed to do e.g. a short-handled sledgehammer or a long-handled hammer. What's the point of making Oberon-07 like Component Pascal when you already have Component Pascal? I would not dream of trying to use a 'bloated' language like Component Pascal to program a single-tasking application for a microcontroller with 16 KB of RAM. I would also not attempt to use a 'crippled' language like Oberon-07 to write a multi-tasking, event-driven GUI program running on a system with 16GB of RAM. However, I do use the 'highly efficient' Oberon-07 to program microcontrollers with 16 KB of RAM. I also use the 'extremely powerful' Component Pascal to write GUI programs for a system with 16GB of RAM. Regards, Chris Burrows CFB Software http://www.astrobe.com ------------------------------ Message: 4 Date: Sat, 30 Sep 2017 02:56:30 +0000 From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> To: "chris(a)cfbsoftware.com" <chris(a)cfbsoftware.com>, ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Procedure variables and local procedures Message-ID: <DM5PR0701MB3672C300B9589480B3587BDBFF7F0(a)DM5PR0701MB3672.namprd07.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" > I would not dream of trying to use a 'bloated' language like Component > Pascal to program a single-tasking application for a microcontroller with 16 > KB of RAM. I would also not attempt to use a 'crippled' language like > Oberon-07 to write a multi-tasking, event-driven GUI program running on a > system with 16GB of RAM. Chris: this is a very interesting point. A few posts ago I implied that Oberon-07 looks like a microcontroller language. Frankly, I expected to get spanked. Now you are saying the same. Would ETH folks agree? Was Oberon not meant as a pinnacle of language design, capable of the most demanding tasks like writing compilers and operating systems? Will the authors feel offended by the word "microcontroller"? So is Oberon-07 intended to be a frugal general purpose language, or was it meant to be a minimalistic microcontroller language? I can hold to my opinions, but what were the authors' intentions? W ------------------------------ Message: 5 Date: Sat, 30 Sep 2017 03:07:10 +0000 From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> To: "chris(a)cfbsoftware.com" <chris(a)cfbsoftware.com>, ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Procedure variables and local procedures Message-ID: <DM5PR0701MB367228D88B23D3D5F90A6B9DFF7F0(a)DM5PR0701MB3672.namprd07.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" > Runtime overflows (INTEGER as well as BYTE) are not trapped in Project > Oberon or Astrobe Oberon. In fact the Random function exploits this > behaviour and would break if ported to a system that didn't allow you to > turn off overflow trapping. Another good point! Overflowing is a crucial part of some digital filters in FPGAs. Without overflowing these filters would not work. Another, slightly less exotic example is a circular buffer design whose pointer must overflow in order to make the buffer circular. I use this design pattern all over my FPGA firmware. In a computer language one can use an IF statement or a modulo operator, but in the FPGA there is hardly place for such embellishments. Most often I just let the upper bit fall off. W. ------------------------------ Message: 6 Date: Sat, 30 Sep 2017 09:23:10 +0200 From: J?rg <joerg.straube(a)iaeth.ch> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Procedure variables and local procedures Message-ID: <66D4EA77-43ED-4830-BCAC-880D2F868A09(a)iaeth.ch> Content-Type: text/plain; charset=utf-8 Wojtek > I am guessing that Chris has the above in mind. I second his opinion: without the dynamic arrays (or "open arrays") the language is crippled. Oberon-07 has open arrays. Open arrays are formal parameters whose length is not known at compile time. Here an example in Oberon-07: PROCEDURE Max(v: ARRAY OF REAL): REAL; (* ?v? is an open array *) VAR i: INTEGER; max: REAL; BEGIN max := v[0]; FOR i := 1 TO LEN(v)-1 DO IF v[i]>max THEN max := v[i] END END RETURN max END Max; and use Max() with vectors of different lengths like v1: ARRAY 10 OF REAL; v2: ARRAY 88 OF REAL; If you would like to write a library operating on two dimensional matrices, you can do so in Oberon-07. It is left as an exercise how to implement MODULE Matrix; TYPE Matrix* = POINTER TO MatrixDesc; MatrixDesc = RECORD m*: PROCEDURE (i, j: INTEGER): REAL (* m(i, j) returns an elem of the matrix *) END; PROCEDURE Allocate*(m: Matrix; dim1, dim2: INTEGER); PROCEDURE Initialize*(m: Matrix; f: Files.File); PROCEDURE EigenValue*(m: Matrix): REAL; END Matrix. As all this is possible in Oberon-07, I was wondering what dynamic arrays are. br J?rg ------------------------------ Message: 7 Date: Sat, 30 Sep 2017 11:56:41 +0200 From: chris <chris(a)gcjd.org> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Procedure variables and local procedures Message-ID: <20170930115641240305.32164927(a)gcjd.org> Content-Type: text/plain; charset=iso-8859-13 On Sat, 30 Sep 2017 02:33:16 +0200, J?rg wrote: >> VAR b : BYTE; i : INTEGER; >> i := 1000; b := i; >> >> Does it trap for overflow? > > The compiler does not generate a trap. It moves the lowest byte of i > to b. See first IF in ORG.Store. Well, that is considered good style? In my opinion this kind of low level action should not be in the base language. If it's defined to be "least significant byte" that would be a bit better, but this could result in some surprise on different hardware. Leaving this undefined in the language report makes the type BYTE an unusable feature for portable programs. > Would you please explain ?dynamic arrays?? Do you miss the low level > SYSTEM.NEW(p, n)? I mean things like: TYPE CharPtr = POINTER TO ARRAY OF CHAR; VAR p : CharPtr; BEGIN NEW(p, 1234); There is nothing low level here. That is a widely used feature in ETH Oberon (System 3) or whatever you call it today. What is wrong with this? Even if I had to write a string librarary for UTF8 I would use this feature for the buffers internally and not linked list of fixed (compile time determined) sized pieces. Greeting, chris ------------------------------ Subject: Digest Footer -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon ------------------------------ End of Oberon Digest, Vol 160, Issue 26 ***************************************

2 1

Procedure variables and local procedures
by Andreas Pirklbauer 30 Sep '17

30 Sep '17

> chris chris at gcjd.org Sat Sep 30 11:56:41 CEST 2017 > > I mean things like: > > TYPE CharPtr = POINTER TO ARRAY OF CHAR; > > VAR p : CharPtr; > BEGIN NEW(p, 1234); > > There is nothing low level here. That is a widely used feature > in ETH Oberon (System 3) or > whatever you call it today. What > is wrong with this? Even if I had to > write a string librarary for UTF8 I > would use this feature for the > buffers internally and not linked list > of fixed (compile time determined) > sized pieces. > > Greeting, chris If you really need this the ability to call NEW(p, 1234) in Oberon-07, you can just add it back from github.com/andreaspirklbauer/Oberon-generic-heap-allocation However, don't expect backward compatibility with Oberon-07 ;-) -AP

1 0

Procedure variables and local procedures
by Andreas Pirklbauer 29 Sep '17

29 Sep '17

> On Fri Sep 29 at 20:18:04 CEST Claudio Nieder wrote: > > If this my understanding is correct, then the question > which arises is, why are there still local procedures? > In my eyes nested procedures seem to make only > sense to facilitate the access to intermediate > variables. Eliminating access to intermediate > variables them to make stuff simple you > should also remove nested procedures. > > claudio One may argue about that. The answers usually given are along the following lines: 1. Sometimes it is desirable to nest a procedure to indicate that it is called only from the enclosing procedure. 2. Adding local procedures to the language comes practically for free, so long as access to intermediate variables is not a requirement. In that case, it simply does not make anything more complicated. 3. The desire to keep the language specification unchanged (note that the restriction introduced with Oberon-07 had no impact on the language definition, as the question of which variables can be accessed is left open in the language report). Personally, as an application programmer I am indifferent, as a very rarely use local procedures - only when reason #1 appears appealing enough in a particular situation. But other programmers may have different criteria or preferences. As a compiler implementor I do care a lot about whether access to intermediate variables needs to be provided or not. But once it has been decided that one does *not* have to implement this feature (as is the case in Oberon-07), I am again indifferent. It just makes no difference to the compiler in that case. But as Paul said earlier in this discussion, to a certain degree it's a matter of taste. --AP .

1 0

Re: [Oberon] Oberon Digest, Vol 160, Issue 22
by Søren Renner 29 Sep '17

29 Sep '17

I don't know what the exhortation to "bottom-post if you can" is asking me to do! On Thu, Sep 28, 2017 at 2:27 PM, <oberon-request(a)lists.inf.ethz.ch> wrote: > Send Oberon mailing list submissions to > oberon(a)lists.inf.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.inf.ethz.ch/mailman/listinfo/oberon > or, via email, send a message with subject or body 'help' to > oberon-request(a)lists.inf.ethz.ch > > You can reach the person managing the list at > oberon-owner(a)lists.inf.ethz.ch > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Oberon digest..." > > > Today's Topics: > > 1. Procedure variables and local procedures (August Karlstrom) > 2. Re: Oberon Digest, Vol 160, Issue 21 (S?ren Renner) > 3. Raytracing research (Skulski, Wojciech) > 4. Re: Oberon Digest, Vol 160, Issue 21 (Liam Proven) > 5. A2 on ARM Linux Platform (Skulski, Wojciech) > 6. Re: Oberon Digest, Vol 160, Issue 21 (Peter Matthias) > 7. Procedure variables and local procedures (Andreas Pirklbauer) > 8. Procedure variables and local procedures (Andreas Pirklbauer) > 9. Re: Procedure variables and local procedures (Skulski, Wojciech) > 10. Re: Procedure variables and local procedures (Skulski, Wojciech) > 11. Procedure variables and local procedures (Andreas Pirklbauer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Sep 2017 12:14:29 +0200 > From: August Karlstrom <fusionfile(a)gmail.com> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] Procedure variables and local procedures > Message-ID: <4b1fd5a6-3768-0117-5e80-c9597a5975b6(a)gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > In the latest revision of the Oberon language, access to identifiers in > intermediate scopes is denied. Doesn't this imply that the restriction > that only globally defined procedures can be assigned to procedure > variables, is the unnecessary? > > -- August > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Sep 2017 08:47:09 -0400 > From: S?ren Renner <soren.renner(a)gmail.com> > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] Oberon Digest, Vol 160, Issue 21 > Message-ID: > <CAJuGca_ooAL8BHLn6EiZ7S8PkC-yRAfnp7swNNRHMGP3jYEbOw@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Also, AOS and Oberon will become much more widely noticed as soon as my > raytracing research receives the attention and praise that it deserves. > > On Thu, Sep 28, 2017 at 6:00 AM, <oberon-request(a)lists.inf.ethz.ch> wrote: > > > Send Oberon mailing list submissions to > > oberon(a)lists.inf.ethz.ch > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > or, via email, send a message with subject or body 'help' to > > oberon-request(a)lists.inf.ethz.ch > > > > You can reach the person managing the list at > > oberon-owner(a)lists.inf.ethz.ch > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Oberon digest..." > > > > > > Today's Topics: > > > > 1. Re: General - Academic vs Commercial applications > > (Felix Friedrich) > > 2. Re: General - Xerox PARC 1970 (Tomas Kral) > > 3. Re (2): General - Academic vs Commercial applications > > (peter(a)easthope.ca) > > 4. NativeOberon's FileName limitations - HOW2 extend? (eas lab) > > 5. Re: General - Academic vs Commercial applications (eas lab) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 27 Sep 2017 12:17:23 +0200 > > From: Felix Friedrich <felix.friedrich(a)inf.ethz.ch> > > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > > Subject: Re: [Oberon] General - Academic vs Commercial applications > > Message-ID: <d04806c6-955e-fa5d-d726-09ba6622c2c5(a)inf.ethz.ch> > > Content-Type: text/plain; charset="utf-8"; format=flowed > > > > In fact Oberon is still taught at ETH Zurich. > > > > We are giving a course on System Construction and discuss some Oberon > > language dialects, Oberon inspired operating or runtime systems and > > programmable hardware supporting or based on Oberon related languages > > and systems. In more detail we teach > > > > (a) The Minos Runtime System (based on HeliOS, system control for > > unmanned helicopters), programmed in a dialect of Oberon07 [FF] > > (b) The A2 runtime system and GUI together with Active Oberon [FF] > > (c) Oberon running on FPGAs: the RISC processor [Paul Reed] > > (d) Systems on a Chip, FPGA and Hybrid Systems, programmed using Active > > Cells, another dialect of Oberon [FF] > > > > cf. http://lec.inf.ethz.ch/syscon/2017/ > > > > Without exaggeration and with a little bit of pride I can say that > > students like this course a lot -- because we really show how these > > systems work behind the scenes over all levels. We (Paul and I) can say > > that we understand every single bit of it and bring this accross as a > > strong argument for simplicity. > > > > Apart from that I am the "last man standing" for Oberon at ETH. I have a > > lecturer position at ETH and am giving large computer science service > > courses at ETH (hundred of students, C++, Java or whatever is > > requested), which limits my time for working with and for Oberon. I love > > to play around with the language, compiler and runtime systems and > > optimize them according to what I, personally, find the most optimal way > > to present or use the langauge. Because much is driven by personal > > taste, I hesitate to sell my own ideas as "the truth", while I have some > > strong opinions. I feel responsible for the A2 repository comprising the > > A2 Multicore OS, its graphical user Interface and the FoxCompiler > > toolchain. > > > > I should not forget to mention that the dialects of Oberon and the > > systems that we teach are in use in real-world commercial systems sold > > by companies that in fact use Oberon for commercial development. For our > > course this is a very important argument underpinning that following the > > principle of simplicity can have very positive practical impact, even if > > it is hard to sell academically. > > > > Kind regards > > Felix Friedrich > > > > > > > > > > > On Tue, 26 Sep 2017 10:36:35 +0000 > > > Treutwein Bernhard <Bernhard.Treutwein(a)Verwaltung.Uni-Muenchen.DE> > > > wrote: > > > > > >> yes, afaik, with the retirement of J?rg Gutknecht the "Native Systems > > >> Group" was shut down. > > > Having said that, Oberon is no longer taught, developed, and included > > > in informatics research sylabus, at ETH University? > > > > > > So is AOS dropped as well? > > > > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 27 Sep 2017 12:49:38 +0200 > > From: Tomas Kral <thomas.kral(a)email.cz> > > To: oberon(a)lists.inf.ethz.ch > > Subject: Re: [Oberon] General - Xerox PARC 1970 > > Message-ID: <20170927124938.6c945698@raspberrypi> > > Content-Type: text/plain; charset=UTF-8 > > > > On Sun, 24 Sep 2017 03:30:24 -0700 > > Douglas G Danforth <danforth(a)greenwoodfarm.com> wrote: > > > > > She showed me the Alto when I visited PARC.? Its hard drive was a > > > large platter which, iirc, held only of data. > > > > 14MB given the enthropy of information may seem like today's 14GB, as I > > see similar stuff on Alto's screen as on mobile displays, say from > > a higher level of perspective, so to speak. That is 1970. > > > > I remember a decade after (1982 ZX/ATARI, etc), popular 8-bit home > > computing, 64K of RAM was unheard of limit, possible only in mainframes > > before. > > > > Then `1984' - Orwell's Big Brother was chosen as the main theme of > > Apple's marketing campaign, for their computer released 1984. > > > > Workstation's like Alto, were a dream, also the price $40.000, > > something like that. Which was not a market price just the cost of > > development, probably? > > > > I am lead to believe, that what maters is relative performance. > > > > Between various releases of today's user s/w, I usually notice, slower, > > more complicated and requiring faster h/w, but that could well be my > > paranoia as I get older :-) > > > > -- > > Tomas Kral <thomas.kral(a)email.cz> > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 27 Sep 2017 09:58:27 -0700 > > From: peter(a)easthope.ca > > To: oberon(a)lists.inf.ethz.ch > > Subject: [Oberon] Re (2): General - Academic vs Commercial > > applications > > Message-ID: <E1dxFfH-0000rF-Hc(a)xo-53-1d-bb.localdomain> > > > > Felix, > > > > Thanks for your overview. > > > > From: Felix Friedrich <felix.friedrich(a)inf.ethz.ch> > > Date: Wed, 27 Sep 2017 12:17:23 +0200 > > > Apart from that I am the "last man standing" for Oberon at ETH. > > > > One is better than zero. Thanks for your dedication! This > > circumstance is a good argument for incuding the language report for > > Active Oberon as HTML in the wikibook. Being a wiki, anyone can work > > on it. Subject to your permission of course. > > > > Incidentally, accesses to the front page has settled to 400-500/month. > > https://en.wikibooks.org/w/index.php?title=Oberon&action=info > > Certain to climb as the content increases and improves. > > > > Regards, ... Lyall E. > > -- > > > > 123456789 123456789 123456789 123456789 123456789 123456789 123456789 > > Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 > > http://easthope.ca/Peter.html Bcc: peter at easthope. ca > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Wed, 27 Sep 2017 17:09:16 +0000 > > From: eas lab <lab.eas(a)gmail.com> > > To: <oberon(a)inf.ethz.ch> > > Subject: [Oberon] NativeOberon's FileName limitations - HOW2 extend? > > Message-ID: > > <CAN3-DLH2igPv3gRQFWk8CCPh_frLdqLEpode9r-5sFjCYJ67Pg@ > > mail.gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > Linux : X11 is a monster, but LNO [121104] runs in a FrameBuffer nicely; > > also under 64bit. > > Why would you NEED LNO ? > > 1. to have multiple files visible together on the same screen; > > 2. with powerfull mouse-chording ability; > > PublicDomain wily [needs X11], copied from ETHO, is even better, except > > lacks > > 3. ETHO's coloring capability: to give an extra dimension to > > complex relationships between texts, possibly in multiple files. > > > > Mildly complex tasks, soon need 4, 5, 6 ...TextFrames viewable-together. > > Since screen-area is the limiting factor, M$'s wastefull <staggered > > frames>, > > copied by Aos, is NOT acceptable. The paper-book, where each of hundreds > > of pages "automatically line-up", is a magical concept! > > > > The big problem/weakness of LNO: not being able to immediately read/write > > to files anywhere in the file-tree, can be reduced by: > > 1. use a convenient file-navigator, like mc, which allows to > > 2. <push a button> at the reqired-file, which stores its /PATH/Name to a > > fixed location, which > > 3. is accessed by LNO to mount the file-to-be-accessed by LNO. > > > > Right now, while composing this text, via USBstik:Linux:TinyCore46:LNO > > I want to access some Oberon:V4 files on the M$-partition. > > I failed: apparently LNO can't mount FATFS, like LEO can. > > It shouldn't be difficult to extend the capability? > > > > But read/write to V4 files in LinuxFS, is OK via: > > FileSystem.Mount V4 LinuxFS /mnt/sdb2/CRG/ETHO/V4dirTree/ > > usr/local/oberon/Text/~ > > > > The 4-string command/M.P had the last/long string stored in the known > > location; > > so "V4" is my chosen name and string1, string3 are in the <Tools Text>; > > and the user need only add his chosen name to make the 4-string command. > > Then System.Directory ^ V4:* lists the directory contents; giving > > immediate > > access to the 96 files:----------- > > V4:. > > V4:.. > > V4:Analyzer.Tool > > V4:AsciiCoder.Tool > > V4:Backup.Tool > > V4:Balloon.Text > > V4:BalloonIdx.hlp > > ... > > V4:Find.Tool > > > > V4:Welcome.Text > > V4:Xref.Tool > > > > 96 files ---------------- > > LNO can access all: Aos, *nix, FATFS and presumably V4 formats. > > The PROBLEM remains, to access eg. "tmp:mc-root", where "mc-root" > > is not a valid <FileName>. > > AFAIR <Linux ETH Oberon> was able to access such filenames by quoting? > > Can we extend LNO, perhaps based on LEO? > > > > == Chris Glur. > > > > PS. The fact that ETHO's System.Directory output is not available: > > ordered by recentcy, is a serious deficiency: not acknowledging that > > <the stack and tree> are central to cognition & thus computing ? > > > > > > ------------------------------ > > > > Message: 5 > > Date: Thu, 28 Sep 2017 01:51:22 +0000 > > From: eas lab <lab.eas(a)gmail.com> > > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > > Subject: Re: [Oberon] General - Academic vs Commercial applications > > Message-ID: > > <CAN3-DLGTDX=a5fnxA7=w54ZsMjzh6ZY4Y22xMtga2OtrJ++Oww@mail. > > gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > Looks like a brilliant syllabus: teaching universal 1st-principles, > > and not just the current FB, twitter fads. > > > > When RPi first came out, I wanted to build a P-code interpreter, > > as I had done in the 70s for Fairchild-F8, 63xx/68xx, Intel16bit; > > but I couldn't see how to <single step design asm-instructions> > > [as I had always done - I coded the F8 via a teletype in *HEX*] > > since appaently the ARM assembler takes the user's <intentions> > > and OPTIMISES it, in the background, to generate the actual. > > single-instructions. > > > > No one on the RPi NNTP could understand my query, because today > > it's always "doA, doB...", without understanding the underlying > > principles. But now, I see the critical reference to "OPTIMIZED" in > > http://lec.inf.ethz.ch/syscon/2017/slides/LSC17Slides0926.pdf > > > > == Chris Glur. > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > > > > ------------------------------ > > > > End of Oberon Digest, Vol 160, Issue 21 > > *************************************** > > >

3 2