January 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

Debugging FPGA oberon via serial line?
by Michael Schierl 29 May '20

29 May '20

Hello, while I was adding UTF-8 support to Fonts and Texts (and almost rewriting Fonts so that a font can be loaded partially and not all glyphs at once), I noticed that debugging such a system can be cumbersome (as you cannot read the TRAP output any more, as well as you have to reset the system to a previous state to be able to fix your mistakes if the screen is too garbled to be useful, or if the system TRAPs during boot). By the way, here is Oberon running in the browser with UTF-8 support for Texts (and Tahoma font): http://schierlm.github.io/OberonEmulator/emu.html?image=UnicodeDiskImage >From other (older) systems, I know it is possible to debug them via serial line, so I was thinking how much the FPGA oberon system needs to be changed (hardware side/software side) to accommodate this. RS232 is supported, so you could use one FPGA system (or emulator) to debug the other one. And I was wondering if anybody already tried doing something like this. I know that Colby Russell worked on debug support in the emulator, but no idea about how far he got. A minimal feature set to be useful (in my opinion) would be - Read and write memory and disk via serial port while the system is running/idle (already possible today via ORC / PCLink) - Set and remove software breakpoints while the system is running/idle - When software breakpoint or trap is hit, save processor state and allow debugging via serial port (-> suspended) - Read and write registers and memory while the system is suspended - Set and remove software breakpoints while the system is suspended - Continue execution when the system is suspended More advanced features would be single stepping (can be emulated by having a look at the instruction and setting software breakpoints at all following locations), or memory breakpoints. Also to be able to enter the debugger by pressing a hardware button on the FPGA (similar to the current reset functionality, but not resetting). And of course symbolic debugging :) Software breakpoints should be easy, just replace instruction by BL to a fixed address. Restore the instruction before returning. For catching TRAPs, overwrite the TRAP address. Saving processor state might be tricky, especially SYSTEM.H and the flags, and maybe you have problems since you need at least one spare register to be able to save the registers to a fixed location in memory. You will also need to switch stack to a second stack before the stack is accessed by the code. Probably solvable by using a special compiler that leaves a register or two unused. Restoring SYSTEM.H and Flags is also not supported (except by searching for instructions that will result in the desired flags or results). Also the question is whether returning to the code will not destroy some flags again. And you need to make sure not to set breakpoints or break at points where a BL has happened but the link register has not been saved yet. So (similar to interrupt) probably some hardware support is needed for this. Entering the debugger by button also needs hardware support (since the current Reset button forgets the PC and some other state). Once in suspend mode, it might be hard to avoid allocating memory, since you cannot run the GC which might collect objects that are still used by the suspended program. But that should be feasible if the functions are basic enough to work with a fixed buffer (e.g. number of breakpoints is limited). I guess memory breakpoints are only possible with hardware support for them (I have no idea how to emulate them except emulating or setting breakpoints at all LOAD/STORE instructions). For symbolic debugging, the compiler would have to write some more debug symbols. For a start, <https://github.com/schierlm/OberonXref/blob/master/ORG.Mod.patch> annotates the code position for every instruction; I currently use it for creating combined source/assembly listings like <https://schierlm.github.io/OberonXref/ProjectOberon2013/ORP.html#both>. But you would probably also need some information about the stack layout (variable names and types) and register contents for every code locatoin, as well as information about module/global variables, and not-exported record types and record members. And you would also need some client to utilize all this information so that you can do something like "Debugger.Inspect F.vwr.dsc" :) So I guess for my own needs, that's too much work for the benefit (especially since I don't know if I will ever try to rewrite any of the core modules again). But perhaps I'm missing something? Any better ideas? Regards, Michael

1 1

A2 Repository
by peter＠easthope.ca 13 Apr '20

13 Apr '20

Hi, rev.9527 on Guenter's Web site is dated September 26. >From felix.friedrich ... Wed Jul 3 09:30:57 2019 > We are currently investing effort into cleaning up A2 ... > ... > ... we will make sure that native versions are properly supported again. > ... need to finish this work before October. Are native versions suitable for end users now? Hold off a little longer? Thanks, ... Peter E. -- https://en.wikibooks.org/wiki/Medical_Machines Tel: +1 604 670 0140 Bcc: peter at easthope. ca

3 4

Re (2): Oberon.Text and "Registry".
by peter＠easthope.ca 29 Jan '20

29 Jan '20

Joerg and all, From: =?UTF-8?B?SsO2cmc=?= <joerg.straube(a)iaeth.ch> Date: Wed, 29 Jan 2020 06:38:10 +0100 > If you want to configure your SW you have at least three options. The > following sample code demonstrates these options with an imaginary > command "setaccount" of an imaginary mail client. > ... Thanks. The general explanation is informative and helpful. I still wonder about the specific meaning of "Registry" in S3 and A2O. >From comments in sources of those systems, I'm fairly certain the reference is to content of Oberon.Text. My "best guess" is the content beginning with LinkSchemes. ETH alumni might find my question unimportant. Someone with a broad and thorough understanding of Oberon systems can say "I don't know exactly what X meant when he wrote the comment. I understand how the system is configured and that's what matters." In my limited understanding, V5 is configured as in Joerg's case c). Thanks again, ... L. -- https://en.wikibooks.org/wiki/Medical_Machines https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0

Oberon.Text and "Registry".
by peter＠easthope.ca 29 Jan '20

29 Jan '20

Hi, S3 and A2O (is A2O an acceptable name for the Oberon subsystem of A2?) are configured by content of the file Oberon.Text. V5 doesn't have Oberon.Text. Can anyone tell how V2 and V4 were configured? The sources of S3 and A2O have scattered references to the "Registry". That is the content of Oberon.Text beginning with LinkSchemes? I've added "Oberon.Text" and "Registry" to https://en.wikibooks.org/wiki/Oberon#Glossary . Corrections welcome. Thanks, ... Lyall E. -- https://en.wikibooks.org/wiki/Medical_Machines https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

Re: [Oberon] 30th anniversary of Oberon
by Joerg 06 Jan '20

06 Jan '20

I tried to quickly collect the differences of Oberon87 and Oberon90. Perhaps I missed some: 1) What is exported? 87: mentioned in DEFINITION 90: declaration marked with * 2) What is a string? 87: enclosed by “ “ or ‘ ‘ 90: enclosed by “ “ 3) reserved words 87: 31+CLOSE, DEFINITION, IMPLEMENTATION 90: 31+MODULE 4) predefined identifier 87: 29 + BYTE, ADR, LSH, ROT 90: 29 + BYTE (this is a typo in the report!!) 5) Module SYSTEM 87: no 90: yes (ADR, LSH, ROT, BYTE, BIT, VAL, NEW) 6) WHILE with ELSIF 87: yes 90: no 7) formal parameter for any actual parameter 87: ARRAY OF BYTE 90: ARRAY OF SYSTEM.BYTE 8) LEN(v) equivalent to LEN(v, 0) 87: no 90: yes 9) alias import 87: IMPORT M : M0; 90: IMPORT M := M0; br Jörg >> Am 02.01.2020 um 10:54 schrieb Nemo Nusquam <cym224(a)gmail.com>: >> >> On 01/01/20 18:25, Chris Burrows wrote (in part): >> The first time I heard of Oberon was when the article "From Modula to Oberon" was posted on the bulletin board of the Journal of Pascal, Ada and Modula-2. It was timestamped Tue Feb 23 20:43:46 1988. > > There was an article in SP&E vol 18,7 pp 671-690, Jul 1988 (with corrections in vol 19,1 Jan 1989) that specified an Oberon with separate definition/implementation modules. > > N. > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

2 2

Re: [Oberon] 30th anniversary of Oberon
by rochus.keller＠bluewin.ch 05 Jan '20

05 Jan '20

@ Pablo Cayuela Thank you very much for the copy. It also references https://doi.org/10.3929/ethz-a-000487176 where 1985 is mentioned as the official start of the project. Meanwhile I also had a look at the Oberon Guide which confirms 1985. @ Nemo Nusquam Thanks for the hint. I had a look at the site (see e.g. http://www.mathematik.uni-ulm.de/oberon/ftp/i386/archive/) but the earliest source I found is from 2004. Could you provide me with a link to the "Oberon 88 with full source" please. @ Joerg Straube Thanks for the links. As far as I can see these are the same documents that were already referenced in this discussion. I assume you intended to combine all references into one post? Best R.

2 1

Re: [Oberon] 30th anniversary of Oberon
by rochus.keller＠bluewin.ch 05 Jan '20

05 Jan '20

@ Chris Burrows Thanks for the information. There seems to be a contradiction with "The Third ACM SIGPLAN History of Programming Languages Conference (HOPL-III)" (2007, https://dl.acm.org/doi/10.1145/1238844.1411838) which states on page 3-8: "The first ideas leading to Oberon were drafted in 1985, and the language was fully defined in early 1986 in close cooperation with J. Gutknecht. The report was only 16 pages long [28]. [...] The entire system was programmed by Gutknecht and the author as a spare time activity over more than two years as described in [31]. The system was released in 1989". [28] points to "The Programming Language Oberon", Software - Practice and Experience, 18, 7 (July 1988), pp. 671-690. That's one of the reasons why usually official publication dates are used, such as the 1987 https://doi.org/10.3929/ethz-a-005363226. Best R. _______________________________ From: Chris Burrows Sent on: Sat, 04 Jan 2020 05:55:52 +0100 To: ETH Oberon and related systems Cc: Subject: Re: [Oberon] 30th anniversary of Oberon 2011 wasn't the birthday of the Oberon language (report / compiler / implementation / whatever) - it was the anniversary of the start of Project Oberon. "Programming was started in early 1986, and a first version of the system was released in the fall of 1988". (Project Oberon - The Design of an Operating System and Compiler) Regards, Chris Burrows https://www.astrobe.com

4 4

Re: [Oberon] 30th anniversary of Oberon
by rochus.keller＠bluewin.ch 05 Jan '20

05 Jan '20

@ Treutwein Bernhard & Joerg Straube Thanks for your responses. >> what do you want to do with it? If nobody else has done or want to do it I would like to add an Oberon group and repository to GitHub with a branch per major version so it is possible to analyse how it evolved, and in my case especially what language version were used. I have my own parser and don't need to generate code. >> access to early versions is quite difficult at least for versions which were not officially published. That's a pitty. How do we know which versions were officially published? I assume there was one in 1988 for the https://doi.org/10.3929/ethz-a-000487176 publication. There were two issues of the Oberon Guide in 1989 (https://doi.org/10.3929/ethz-a-005363230 and https://doi.org/10.3929/ethz-a-000508514) and a 1989 release was mentioned in the HOPL paper. There was likely at least another release in 1990. But these are just assumptions. Best R. _______________________________ From: Treutwein Bernhard Sent on: Sun, 05 Jan 2020 13:57:47 +0100 To: oberon(a)lists.inf.ethz.ch Cc: Subject: RE: [Oberon] 30th anniversary of Oberon > Do we actually have access to the source code of the earlier versions of the Oberon System, especially the one referred to by the I fear that access to early versions is quite difficult at least for versions which were not officially published. -- Bernhard _______________________________ From: Joerg Sent on: Sun, 05 Jan 2020 13:52:02 +0100 To: rochus.keller(a)bluewin.ch ; ETH Oberon and related systems Cc: Subject: Re: [Oberon] 30th anniversary of Oberon > Do we actually have access to the source code of the earlier versions of the Oberon System, especially the one referred to by the 1988 paper (see https://doi.org/10.3929/ethz-a-000487176, ... I don‘t. The question is: what do you want to do with it? You will need access to a Ceres machine or Ceres emulator. The compiler will generate code for the NS32032, Display.Mod will need the Ceres screen and Mouse.Mod will connect to what ever mouse HW was hip at that time. Jörg

2 1

Re: [Oberon] 30th anniversary of Oberon
by Treutwein Bernhard 05 Jan '20

05 Jan '20

> Do we actually have access to the source code of the earlier versions of the Oberon System, especially the one referred to by the I fear that access to early versions is quite difficult at least for versions which were not officially published. -- Bernhard -- Bernhard Treutwein (vom Mobiltelefon aus gesendet)

2 1