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

Re (3): Oberon Wikibook
by peter＠easthope.ca 23 Mar '17

23 Mar '17

From: Treutwein Bernhard <Bernhard.Treutwein(a)Verwaltung.Uni-Muenchen> Date: Thu, 16 Mar 2017 14:39:38 +0000 >>> ... it should include a git or svn base code repository >>> with an appropriate viewer for binary source code files. >> >>How? In a Wikibook, I might have a solution for that difficulty. > > there is Claudio Nieders Text filter written in Java, which should do the job: > https://sourceforge.net/p/oberon/oberonv4/ci/master/tree/utils/ch/claudio/o… There should be no more than one external dependancy, the repository server. Java will require another external system; until Java is in Oberon at least. > How do you want to realize it in a Wikibook? As simple as possible. An Oberon module is a page in the Wikibook. git and svn are cumbersome beasts which Oberon can not peruse. Avoid them. 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

1 0

FPGA Oberon - Modules.rsc
by Andreas Pirklbauer 22 Mar '17

22 Mar '17

Thomas, see the answers inline below. > thomas.kral at email.cz thomas.kral at email.cz Wed Mar 22 15:40:42 CET 2017 > In the chapter 14.2 it hints that linker is almost identical to `Modules. > Mod' loader, except it links statically into a file, rather than into memory. The linker referred to in the book "Project Oberon" is called ORL.Mod. It corresponds to module Linker.Mod in the repository https://github.com/andreaspirklbauer/Oberon-building-tools <https://github.com/andreaspirklbauer/Oberon-building-tools>. I don’t have access to the source code of ORL.Mod, but from the description in the book, it looks like ORL.Link is doing pretty much what Linker.Link does. If you have a quick glance at the source code of Linker.Mod, you will see that it *is* in fact the Oberon 2013 module loader (i.e. Modules.Load renamed to Linker.Link), line for line - with the *one* important difference that it writes the “loaded” modules into a separate memory area first (instead of modifying the “official” module area itself) and then, at the very end of the linking process, simply writes that area byte for byte to the specified output file. That’s all there is too it — the regular Oberon 2013 module loader, where however the output is written to a file. >Addresses are relocated with origin 0H, from a fixed start of Oberon partition? During the regular Oberon boot process, the regular Oberon boot file (containing the pre-linked binary of the 4 modules of the Oberon inner core, i.e. modules Kernel, FileDir, Files and Kernel) is loaded from the so-called “boot area” of the local disk. In Oberon 2013, the boot area is located in sectors 2-63 of the disk. Looking at the source code of Builder.Load, you can indeed see that it literally overwrites exactly those sectors with the inner core, byte for byte. Then, during the system boot process, the boot loader (BootLoad.Mod) merely reads those sectors from disk and transfers their content byte for byte into main memory, starting at location 0. The number of bytes to be read is extracted from location 16 of the boot file itself (see source code of BootLoad.LoadFromDisk which is less than half a dozen lines of code). Note that the *format* of the Oberon boot file, as transferred into main memory by the boot loader from the boot area of the disk, is *defined* to *exactly* mirror the standard Oberon storage layout, starting at location 0 (See chapter 8.1, page 103, of the book Project Oberon, 2013 Edition, for a detailed description of Oberon’s storage layout). The boot file is *created* this way by Linker.Mod (see Linker.Link, towards the end). In particular, location 0 in the boot file (and later in main memory once it has been loaded) contains a branch instruction to the initialization sequence of the top module of the boot file (i.e. module Modules). Thus, the boot loader (BootLoad.Mod) can simply transfer the boot file byte for byte from the boot area (sectors 2-63) to main memory location 0 during the regular Oberon boot process, and then branch to location 0 – which is *precisely* what it does. And this is why BootLoad.Mod is so simple: just a few lines of code. > I also found found some boot linking modules in native oberon souce files. > ./src/x86/Unix/BootLinker.Mod > ./src/NO/BootLinker.Mod > Was I close? Those are quite similar indeed. These files come from older implementations. I am not using those. The file Linker.Mod that you will find in the repository https://github.com/andreaspirklbauer/Oberon-building-tools <https://github.com/andreaspirklbauer/Oberon-building-tools> has the nice property that it behaves *exactly* like the regular Oberon *2013* module loader (Modules.Load) - because, well, it *is* in fact the module loader, with the one small modification outlined above. So, by keeping the above repository in sync with the official version of the Oberon 2013 module loader, it is *guaranteed* to work with the latest version(s) of Oberon 2013. > What would be also interesting to decompose `prom.mem' to understand how this file could be produced. > It seems to have 361 lines each ascii encoded long word. Ends with C7000000, lines 362-490 are zeros. > Are these RISC machine instructions? The file prom.mem file looks like it is, in essence, the boot loader (think: "BootLoad.rsc re-packaged"). If that is the case, it is supposed to be produced by the command: Builder.WriteFile BootLoad.rsc 512 prom.mem However, I just haven’t gotten around to implement it - first, because I don’t have the specific hardware to test it . . . and second, because I don’t need it. I already *have* a working prom.mem which I don’t intend, nor have any reason, to change. As outlined in the README file of the above repository, there usually is no need to change the boot loader itself. But - in case you intend to implement it - all this command does needs to do is take the binary file for the boot loader (BootLoad.rsc - as generated by the regular Oberon compiler, see the README file for the details), copy it byte for byte to the file “prom.mem", and add a few additional bits of information around it, so that it is compatible with the specific hardware used (e.g. Xilinx FPGA board). For that, one probably needs to read some Xilinx documentation I suppose. PS: Note that Builder.WriteFile corresponds to ORX.WriteFile, but I don’t have the source code of module ORX.Mod either. But the creator of the file prom.mem certainly does. That would be the file you’d need to get. > Many thanks > Tomas ---------- Původní zpráva ---------- Od: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>> Komu: ETH Oberon and related systems <oberon at lists.inf.ethz.ch <https://lists.inf.ethz.ch/mailman/listinfo/oberon>> Datum: 22. 3. 2017 11:36:35 Předmět: [Oberon] FPGA Oberon - Modules.rsc " The book Project Oberon does not describe the way the inner core itself is built (it only mentions that a “boot linker”is needed for that) or loaded onto the boot area of the local disk, nor are the tools to accomplish this published. A minimal set of the Oberon building tools can be found at: <a href='https://github.com/andreaspirklbauer/Oberon-building-tools <https://github.com/andreaspirklbauer/Oberon-building-tools>'>https://github.com/andreaspirklbauer/Oberon-building-tools</a <https://github.com/andreaspirklbauer/Oberon-building-tools%3C/a>> Usage: ORP.Compile Kernel.Mod FileDir.Mod Files.Mod Modules.Mod ~ Linker.Link Modules # prepare inner core (pre-linked binary) Builder.Build Modules # load inner core into boot area of disk --------------------------------------------------------- thomas.kral at email.cz thomas.kral at email.cz Tue Mar 21 09:13:34 CET 2017 Hi Joerg, I was rereading the chapter 14 again, I realise the boot over RS232 is triggered by a switch, but I still do miss the point, how do I build the inner core, and Oberon0. In the text there is a reference to boot linker. Many thanks Tomas ---------- Původní zpráva ---------- Od: Jörg <<a href='https://lists.inf.ethz.ch/mailman/listinfo/oberon <https://lists.inf.ethz.ch/mailman/listinfo/oberon>'>joerg.straube at iaeth.ch</a>> Komu: ETH Oberon and related systems <<a href='https://lists.inf.ethz.ch/mailman/listinfo/oberon <https://lists.inf.ethz.ch/mailman/listinfo/oberon>'>oberon at lists.inf.ethz.ch</a>> Datum: 21. 3. 2017 8:06:54 Předmět: Re: [Oberon] FPGA Oberon - Modules.rsc " The inner core is at a fixed location on the disk. The boot process is described in chapter 14.1: <a href='https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf>'>https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf</a <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf%3C…>> (<a href='https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf>'>https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf</a <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf%3C…>>)

1 0

FPGA Oberon - Modules.rsc
by Andreas Pirklbauer 22 Mar '17

22 Mar '17

The book Project Oberon does not describe the way the inner core itself is built (it only mentions that a “boot linker”is needed for that) or loaded onto the boot area of the local disk, nor are the tools to accomplish this published. A minimal set of the Oberon building tools can be found at: https://github.com/andreaspirklbauer/Oberon-building-tools <https://github.com/andreaspirklbauer/Oberon-building-tools> Usage: ORP.Compile Kernel.Mod FileDir.Mod Files.Mod Modules.Mod ~ Linker.Link Modules # prepare inner core (pre-linked binary) Builder.Build Modules # load inner core into boot area of disk --------------------------------------------------------- thomas.kral at email.cz thomas.kral at email.cz Tue Mar 21 09:13:34 CET 2017 Hi Joerg, I was rereading the chapter 14 again, I realise the boot over RS232 is triggered by a switch, but I still do miss the point, how do I build the inner core, and Oberon0. In the text there is a reference to boot linker. Many thanks Tomas ---------- Původní zpráva ---------- Od: Jörg <joerg.straube at iaeth.ch <https://lists.inf.ethz.ch/mailman/listinfo/oberon>> Komu: ETH Oberon and related systems <oberon at lists.inf.ethz.ch <https://lists.inf.ethz.ch/mailman/listinfo/oberon>> Datum: 21. 3. 2017 8:06:54 Předmět: Re: [Oberon] FPGA Oberon - Modules.rsc " The inner core is at a fixed location on the disk. The boot process is described in chapter 14.1: https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf> (https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf>)

3 2

FPGA Oberon - Modules.rsc
by Tomas Kral 21 Mar '17

21 Mar '17

Hi, I have an interesting observation. `Modules' is loaded as shown by `ShowModules', but I cannot find it on my system, I can only see its `Modules.smb' symbolic file. The question is how it can be loaded if not visible? -- Tomas Kral <thomas.kral(a)email.cz>

4 3

FPGA Oberon - Compiler Updates
by thomas.kral＠email.cz 20 Mar '17

20 Mar '17

Hi, I have managed to recompile Oberon compiler. Initially I had some problems completing the task, as I was getting errors of ORP imports bad key from ORB. I took these steps that resolved successfully. 1) started with initial RISC.img 2) copied ORP,ORG, 201604 updates 3) compiled ORS, ORB, ORG to get .smb files 4) restarted machine 5) compiled ORP 6) backed OR*.rsc to OR*.rsc.Bak, just in case smthg went wrong I could roll it back 7) copied OR*, 201609 updates 8) deleted OR*.smb files 9) compiled ORS, ORB, ORG, ORP I was surprised, I needed to apply updates in two steps, as they appeared since 2015, also that one restart was required. Tomas.

1 0

FPGA Oberon - Building & Maintenance Tools
by Tomas Kral 19 Mar '17

19 Mar '17

Hi, After some month I am toying with `FPGA Oberon Workstation' again. I am rereading most chapters from the Project Oberon 2013. I would like to also try the initial boot over serial line. This demonstrates starting the system from nonexistent `0' state. There is chapter 14. Building & Maintenance Tools, explaining the process. There are these files mentioned, of which I have got, `BootLoad.Mod', `RS232.Mod'. I wish to also have, `ORL.Mod', `Oberon0.Mod', `DiskCheck.Mod', and `Scavenger.Mod', to complete the whole example. Perhaps I am not a careful reader, but could anyone please advise where these could be got? Many thanks. -- Tomas Kral <thomas.kral(a)email.cz>

1 0

Class Methods Vs. Procedure variables in Records
by Andreas Pirklbauer 07 Mar '17

07 Mar '17

When Object Oberon was released in 1989, this was in fact done. Appendix 3 of the Object Oberon report dated June 1989 contains a description of a basic class library written in OOP style, which essentially corresponds to the Original Oberon viewer system. For example, there is a core module “Frames" exporting a class “Frame", which in turn defines a set of methods such as Show, Hide, Resize, Move, Copy, Defocus, Neutralize etc. And there is also a module “TFrames” (in analogy to module TextFrames of Original Oberon) exporting a (sub) class “Frame", which defines methods that override some of the basic methods from the base module “Frames”. But I don’t know how much it was used, and what the experiences were. I haven’t used it myself. —Andreas -------------------------------------------------------------------------- From: Richard Hable informujo at aon.at Sun Mar 5 22:56:49 CET 2017 Am 2017-03-03 um 11:40 schrieb Andreas Pirklbauer: > That is exactly right: There are indeed no type extensions in the > Oberon "inner core" (modules Kernel, FileDir, Files and Modules). And > almost no type extensions in the "outer core" (modules Input, > Display, Viewers, Fonts, Texts, Oberon). The one exception I found is > in module Texts I think, it would actually be a good thing to have more object orientation also in the core modules. It could make the system less static and more adaptable and user friendly. For example, if module TextFrames contained type-bound procedures based on the Frame type instead of a collection of static procedures with a Frame parameter, one could easily adapt its behavior by overriding just a few selected procedures. And if all documents were based on a common type with overridable type-bound command procedures, the user would not have to choose between commands like "Edit.Store" and "Draw.Store", but simply invoke "Store", which would automatically call the right procedure according to the actual document type. Richard

1 1

Class Methods Vs. Procedure variables in Records
by Andreas Pirklbauer 07 Mar '17

07 Mar '17

Richard Hable Tue Feb 28 20:23:00 CET 2017 > > Wirth remains: these languages are still too complex. Why again are > > there separate concepts for structs (=records), classes (=pointers to > > records), modules, and protocols, and extensions, and and .. in Swift, > > when exactly two would do (records for data structuring and modules for > > information hiding)? > > On the other hand, if you use Oberon or Oberon-2, you need at least > three definitions in order to define a simple class: the module > containing the class, a record type containing its member variables, and > a pointer type referring to the record. > > Richard, - - - - - - - - - - - - - - - - - - - - - - - - - - - - . . . which this is why I wrote in my original post of January 3rd, 2017: > Personally, I believe Oberon7 is enough for many purposes, and that > certainly includes system design. And that is why I decided to stick > to the original Oberon language in Experimental Oberon. But that is > entirely my personal bias. From an educational point of view, I would > consider using Oberon-2 instead, as it very nicely and cleanly demonstrated > the various OOP concepts. But in any case, more important than the choice > of the language is, I believe, to teach the debate. You are right, one does indeed need module, record and pointer declarations to implement the OOP style exemplified in the Draw editor that is part of the Original Oberon distribution. On the other hand: Apart from the viewer system and a handful of document editors like Draw, one *could* make the argument that there is not much need for using OOP in many other places. One may of course agree or disagree with that statement -personally, I have no predisposition one way or the other. But as I stated in my original note from Jan 3, 2017, this was (more or less) the essence of the main argument brought forward by the "instance-centered" group at ETH around Prof. Wirth (the "Original Oberon” camp so to speak) in the early 1990 - I was just reporting what has been said back then during the debate. They basically argued: "Look, an entire operating system (the Oberon system) could be advantageously written in the conventional programming style. So this fact alone impressively proves that OOP is not all that essential, even when writing an entire OS. The only exception is the viewer system - which however is done now." This argument, when it is thrown at you, is hard to argue agains, given that the authors of the Oberon system have gone to great lengths of actually implementing it :-) So their argument felt a little bit like this: "Guys, we already did it (once) in the Oberon viewer system, so no need to do it again there. Of course, 'you app developers' out there can use OOP it in a things like document editors where you can use Draw as a template. Just copy it and you’ll see, you’ll fine. It’s all you need. But: this is it! Document editors and, perhaps, a few other scenarios. Where else would you 'really' need OOP?". Indeed, there is only a handful of document editors, not thousands, that have been developed over the years. But of course, despite this rather purist few, people at ETH back then have written other software using the OOP style using either Object Oberon or Oberon-2 — after all, one has to master it, right?. I have used both Object Oberon and Oberon-2 extensively. At one point, even the Oberon-2 compiler itself was reexpressed in Oberon-2, using type extensions and type-bound procedures to distinguish between the different kind of entries in the compiler's list of the declared symbols (the so-called symbol table) for example. Of course [..note: when you were at ETH in those days, one develops a kind of Pavlov effect, in the sense that one already knows what the answer is going to be before it is even given..], the "counter argument" against THAT decision was to state the following: (i) look, a compiler is typically bootstrapped, i.e. it *must* first be written in another language that does not support type extension, such as Modula-2. So in any case, you have to start with a compiler that (almost by definition) cannot possibly use type extension (because it's the feature you are actually implementing for the first time), (ii) not using type extensions makes it easier to translate the compiler into *other* languages, a step that may be necessary in yet another bootstrapping exercise on yet another platform where Oberon-2 is not yet available, and (iii) why again would you use type extensions in a program such as a compiler in the first place when *all* extensions are already known at the time the compiler is written, i.e. the compiler will - by definition - not ever be extended in any substantial way in the future (unless the language itself is changed of course in a substantial way, which however has not happened in the last 25+ years last time I checked). In this particular example, my personal view is that using Oberon-2 does indeed increase the readability of the compiler somewhat - mainly because one no longer has to remember what all those multi-purpose fields for class-specific attributes actually mean. But that is not a particularly strong argument, considering that the entire compiler is now down to only about 2500 lines. You either master THAT or you don't. If you don't, no amount of rewriting it in a a slightly more convenient notation will make you understand it better.. But there are other examples of programs that have been built using Oberon-2. But again, that Pavlov reflex.. Of course, from an educational point of view, it is perhaps indeed asked too much from eg a 16-year old to reconstruct a Draw-like system from scratch. They just won't. And this is why I added my *personal* remark (re-inserted above) which states that the additional elements (class keyword, type-bound procedures, etc) *may* make some sense from a practical point of view - even though the purist may claim they are not really needed. But we don't live in a purely academic world of course!. Imagine an Android or iOS development environment (IDE) with only Oberon or Oberon-2, but no class concept as provided by Java (on Android) or Objective-C/Swift (on iOS). It would not be as easy for many programmers. Many would be lost indeed. I don't see how the platform providers could have achieved the degree of uniformity that they have without certain "templates" pre-canned (and pre-built into) the IDE. All Android and iOS apps look alike (from a principal point of view only of course). The same can certainly *not* be said of Oberon-(1,2). Andreas

3 6

Re: [Oberon] Re (2): Detecting whether a Text is a module source.
by John R. Strohm 05 Mar '17

05 Mar '17

Boyer-Moore string search algorithm? --- peter(a)easthope.ca wrote: From: <peter(a)easthope.ca>, Bob Walkden <bob(a)web-options.com> To: <oberon(a)lists.inf.ethz.ch> Subject: [Oberon] Re (2): Detecting whether a Text is a module source. Date: Sun, 29 Jan 2017 16:10:59 +0000 > According to the EBNF for O7, the smallest legal module ... OK, thanks. Will keep in mind for later. For now I'm concerned only with detecting the presence of a word in a text; not with conformity to a syntax. What is efficient code to find whether the word "Jaguar" is present in a text for example? There are many ways of varying efficiency. A compiler must have a solution but I'm unlikely to recognize it. Can anyone give a code example or direct me to one? Thanks, ... Lyall E.

10 17

Re: [Oberon] The Modula-2 System for Z80 CP/M (Peter Hochstrasser)
by Josef Templ 03 Mar '17

03 Mar '17

I am not absolutely sure but I think you are referring to the Z80 Modula-2 development system by Martin Odersky (plus colleague). Martin Odersky is well known nowadays as the inventor of Scala. Try to contact him via martin.odersky -AT- epfl.ch or at Lightbend (formerly Typesafe), where he is also working. - Josef

1 0