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

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

Re (2): V4 Native?
by peter＠easthope.ca 16 Aug '17

16 Aug '17

From: Claudio Nieder <private(a)claudio.ch> Date: Sat, 29 Jul 2017 12:08:52 +0200 > This list illustrates well the advantage of NOT going native. ... Thanks Claudio. I've revised the V4 entry in the context table. Feel free to correct further or ask for a correction. I haven't found installation instructions or notes for V4. Do any exist? 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

3 2

OP2 Vs Wirth's compiler.
by Andreas Pirklbauer 05 Aug '17

05 Aug '17

The latest RISC5 compiler handles this similar to the original Oberon compiler on Ceres: one single key per module. Thus, when the interface of a module is changed, *all* clients are invalidated. In the specific implementation, the key is simply the sum of all bytes in the symbol file, i.e. really is a checksum. See procedure ORS.Export at http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/ORB.Mod.txt . AP -------------- Josef Templ josef.templ at gmail.com Mon Jul 31 15:52:13 CEST 2017 - Previous message: [Oberon] OP2 Vs Wirth's compiler. - Next message: [Oberon] Re (2): Italicization of comments and emboldening of keywords. - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Besides the abstract syntax tree construction, one difference between OP2 and the original NW Oberon compiler is the compatibility checking across module boundaries. In OP2 there is a separate key (fingerprint) per exported object while in the original compiler there is a single key per module. Thus, whenever anything in a module is changed all clients are invalidated. In OP2 only clients that are using the changed object are invalidated. I don't know how this is handled in the latest RISC5 compiler. - JT

3 4

Re: [Oberon] OP2 Vs Wirth's compiler.
by Josef Templ 31 Jul '17

31 Jul '17

Besides the abstract syntax tree construction, one difference between OP2 and the original NW Oberon compiler is the compatibility checking across module boundaries. In OP2 there is a separate key (fingerprint) per exported object while in the original compiler there is a single key per module. Thus, whenever anything in a module is changed all clients are invalidated. In OP2 only clients that are using the changed object are invalidated. I don't know how this is handled in the latest RISC5 compiler. - JT

1 0

Re (2): Re (2): V4 Native?
by peter＠easthope.ca 31 Jul '17

31 Jul '17

From: Treutwein Bernhard <Bernhard.Treutwein(a)Verwaltung.Uni-Muenchen.DE> > E.g.: Robert Lichtenberger has his notes for Oberon V4 under Linux ... > ... > For Windows, ... Included in the table now. https://en.wikibooks.org/wiki/Oberon#Contexts ... 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

Re: [Oberon] OP2 Vs Wirth's compiler.
by Treutwein Bernhard 30 Jul '17

30 Jul '17

Hi Srinivas > How is OP2 better than Wirth's (simple four module) compiler? jut look at Regi Crelier PhD thesis: in short: OP2 is more portable (as its name also suggests: Oberon Portable Compiler). -- Bernhard -- Bernhard Treutwein (mobil) LMU, Ref.VI.3

3 2

Re: [Oberon] V4 Native?
by Treutwein Bernhard 30 Jul '17

30 Jul '17

> Did V4 ever run on a bare machine? The Linz Web site mentions it > running on Linux, Unix & etc. Not on a bare machine. Afaik: No A V4 Native is something I several times thought about and since the System-3 kernel added persistent objects to Version-2 and V4 and S3 are both based on V2, I guess it should be manageable. The differences between different V4 implementations may be seen/extracted from Claudio Nieders collection, which is available at sourceforge: https://sourceforge.net/p/oberon/oberonv4/ci/master/tree/ and his (together with Ralph Degner) attempt to create a unified V4. See enclosed pdf "Towards a unified Oberon V4". I created that pdf from a Text some time ago and did not find the Text at the moment. -- Bernhard

8 9

Italicization of comments and emboldening of keywords.
by peter＠easthope.ca 30 Jul '17

30 Jul '17

Where were these conventions applied? All of V4, BB, CP and GPCP? Some of these? In a given context, what was the level of adoption? Thanks, ... 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

3 2

Re (3): Italicization of comments and emboldening of keywords.
by peter＠easthope.ca 30 Jul '17

30 Jul '17

From: peter(a)easthope.ca > ... MediaWiki.Markup converts color, boldness and italicization ... P.s. I meant to cite this example. https://en.wikibooks.org/wiki/Oberon/Oberon.HTML.Tool -- 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

Re (2): Italicization of comments and emboldening of keywords.
by peter＠easthope.ca 30 Jul '17

30 Jul '17

From: Chris Burrows <chris(a)cfbsoftware.com> Date: Sun, 30 Jul 2017 10:05:40 +0930 > It is only feasible to apply italicization of comments and emboldening of > keywords on systems that have prettyprinting software (e.g. V4 and BB) or > can be used with an editor with syntax-highlighting capabilities (e.g. > GPCP). Such styling would be too laborious to maintain manually. ... Thanks for explaining Chris. > The appearance of the source code is just a 'view' of > the code. As displayed by PET in LinuxAos for example. > The contents of the source code file is just plain text - it > doesn't contain any embedded font attributes. Therefore will leave modules in the wikibook as plain Text, except for coloring to mark revisions as in some modules in EO. Will stick to this until convinced otherwise at least. Incidentally, MediaWiki.Markup converts color, boldness and italicization of Text into markup which Wikimedia converts to HTML which a browser renders to appear identical or similar to the original Text in Oberon. To be more complete I should add font size. 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