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

Wanted: Oberon Syntax in TextMate, Sublime Text or Atom Grammar
by Treutwein Bernhard 01 Jan '22

01 Jan '22

Does somebody have grammars for Oberon / Oberon-2 / Component Pascal / Active Oberon as grammar for TextMate / Sublime Text / Atom Background: Github wrongly classifies Oberon / Oberon-2 / Component Pascal / Active Oberon as Modula-2. I opened quite some tiome ago an issue in the github/linguist project (https://github.com/github/linguist/issues/3888) and they don't accept EBNF grammars. -- Bernhard Treutwein

6 9

Re: [Oberon] ... MOD 65536
by Hans Klaver 07 Jun '20

07 Jun '20

I wrote: > Now also in Oberon System V5 Hennessy.Mod can be used with ...MOD 65535 in procedure Rand. > All reference output is as it should be. This should be: Now also in Oberon System V5 Hennessy.Mod can be used with ...MOD 65536 in procedure Rand. All reference output is as it should be. -- Hans

9 36

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

Re: [Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)
by Guy T. 03 May '20

03 May '20

I’m following this thread with great interest… I was not expecting this but it is a very interesting discussion. For me, the fundamental question is: What is the community trying to achieve? Some partial answers: - Attract other peoples in the realm of Project Oberon and/or the Oberon language. - Continue the development of Project Oberon in a niche RISC5/fpga based environment. - Extend the Project Oberon to get it run on many different hardware platforms. - Extend the Project Oberon to supply other useful tools to the end user. - Other aspects (like convergence of Oberon dialects, etc.) - All of the above My current personal requirement is to use the Oberon language as a mean to develop IOT applications on a chip that was not looked at by the community up to now. At first, I expected to use it in a “bare metal” manner, but I found impossible to do without taking into account the complexity/lack of openness of some hardware related aspects of the targeted chip (ESP32) and the need to interface the de-facto framework. That framework (ESP-IDF) can be seen as an abstraction layer to the hardware. I would like to see the Oberon OS available on other platforms than the RISC5, not because it’s not a nice idea, but it limits the availability of a functioning platform as the hardware is rather limited in availability. For sure, there is the RISC5 emulator that can be used on many platforms, but I would prefer to see it runs as a main alternative to Windows/Linux/Whatever. Getting it run on a very cheap platform like the Raspberry Pi would be a bonus. It can help attract peoples to the community. To limit the effort of porting the Oberon Project to other platforms, abstracting the hardware is a key aspect, both for the OS and for the compiler. Both aspects need to be resolved. Building an abstraction layer from scratch would be an important challenge. Think about USB, Ethernet, WiFi, Disks Format, etc. The compiler is the easiest portion of porting the project, as long as the community converge to a solution. A first step toward abstracting the hardware could be to use the Linux kernel. Just the kernel, and then build on top of it. You then gain all the drivers for almost every piece of kit available, transforming the OS only once. For the compiler, depending on the choice taken, GCC and its dependencies would be also required. But first, there is a need to converge toward a vision to where, as a community, you/we see the future of this project. Cheers! Guy

7 14

Negative integer literals in Oberon
by Arthur Yefimov 03 May '20

03 May '20

While developing the compiler[1], we got a question whether it is possible to write the following: PROCEDURE DWord(n: INTEGER); ... DWord (90909090H) (where INTEGER is 32-bit). Some compilers give an error (i.e. VOC), while this works in the Project Oberon (2013) compiler. This would turn out to be quite convenient, because the purpose of DWord in our code was to write 4 bytes to the file given as INTEGER (using little-endian byte order). DWord has the following implementation (module Generator[2]): PROCEDURE DWord (n: INTEGER); BEGIN Files.Write (r, CHR (n MOD 100H)); Files.Write (r, CHR (n DIV 100H MOD 100H)); Files.Write (r, CHR (n DIV 10000H MOD 100H)); Files.Write (r, CHR (n DIV 1000000H)) END DWord; The Oberon language report does not indicate that literal 90909090H should be considered an error if INTEGER has 32 bits. In this experiment, an online RISC emulator[3] was used. References: [1] https://github.com/kekcleader/oberon [2] https://github.com/kekcleader/oberon/blob/master/Mod/Generator.Mod [3] http://schierlm.github.io/OberonEmulator/emu-wasm.html?image=FullDiskImage&…

13 82

Type compatibility in Oberon
by Chris Burrows 01 May '20

01 May '20

When I followed the link in the post below the item that really grabbed my attention was the excellent document: Type compatibility in Oberon https://www.miasap.se/obnc/type-compatibility.html It is apparent to me that a lot of thought has gone into the preparation of this document. It would be very useful to any Oberon programmer who was having difficulty understanding why his program would not compile due to a type-compatibility issue. I haven't used OBNC so can't say how well it conforms to these rules - knowing August's great attention to detail I would expect it to be 'very well'. While the Astrobe ARM compilers comply with the vast majority of these rules there are one or two minor exceptions. These are described in the accompanying documentation. You should also expect some very minor relaxations of the rules (e.g. ARRAY OF BYTE parameters) when using the Project Oberon RISC5 compiler. Regards, Chris Burrows CFB Software https://www.astrobe.com > -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > August Karlstrom > Sent: Friday, 1 May 2020 2:00 AM > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] Interfacing with Foreign Systems > > On 2020-04-30 01:50, Skulski, Wojciech wrote: > > Chris: > > > > how about OOC and OO2C? Are they not in the same spirit? > > > > http://ooc.sourceforge.net/index.html > > OBNC is a better example. It targets the latest version of Oberon and is > actively maintained. > > https://www.miasap.se/obnc/ > > > -- August > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

3 3

Re: [Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)
by Guy T. 30 Apr '20

30 Apr '20

Well… I have a Linux kernel configured to run on a single 1.2M disquette (now it is running on usb flash drive) that is used as a proxy computer between the internet and my network. Many routers, software defined radios and other embedded systems are using the kernel without too much assle. The point is you pick and choose the drivers you need. The zillions of line of code are there if you need them but they are not necessary for everything. The kernel is highly configurable. If you need only two drivers, that’s what you will get, nothing else. You compile the kernel and you retrieve a small amount of binary. And it will be still there in 20 years. The inefficiency of Linux come from the huge amount of processes that are running behind the scene. I’m always amazed by the number of processes running in the background (The same for Windows and it’s worse with MacOS). But here, we are taking only the portion of Linux that talk to the hardware that we are interested with. Nothing else. >In Oberon's case it would mean using a multi-megabyte inefficient blob >of millions of lines of code to support a tiny efficient kernel less >than 0.1% of the size. >So, you lose the efficiency, you lose the small size and simplicity, >and you end up with something nearly as bloated as Linux -- but it's a >very poor Linux that's not very compatible.

1 0

Re: [Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)
by Guy T. 30 Apr '20

30 Apr '20

The approach I’ve taken so far is very similar to the "Oberon-2 Programming with Windows”. Here is the modifications to the language I’ve done (from the syntax definition of Oberon-07): Module = OberonModule | CModule. OberonModule = MODULE ident ";" [ImportList] DeclarationSequence [BEGIN StatementSequence] END ident "." . (* No change here *) CModule = MODULE "[" CDECL "]" ident ";" [ImportList] CDeclarationSequence END ident "." . CDeclarationSequence = DeclarationSequence = [CONST {ConstDeclaration ";"}] [TYPE {TypeDeclaration ";"}] [VAR {VariableDeclaration ";"}] {CProcedureDeclaration ";"}. ArrayType = ARRAY ["[" CDECL "]"] length {"," length} OF type. PointerType = POINTER ["[" CDECL "]"] TO type. ProcedureType = PROCEDURE ["[" CDECL "]"] [FormalParameters]. ProcedureDeclaration = OberonProcedureDeclaration | CProcedureDeclaration. OberonProcedureDeclaration = ProcedureHeading ";" ProcedureBody ident. (* No change here *) CProcedureDeclaration = CProcedureHeading ";" . CProcedureHeading = PROCEDURE ["[" CDECL "]"] identdef [FormalParameters]. RecordType = OberonRecordType | CRecordType. OberonRecordType = RECORD ["(" BaseType ")"] [FieldListSequence] END. (* No change here *) CRecordType = RECORD ["[" CDECL "]"] [FieldListSequence] END. —— The only change to the syntax is the use of a "[CDECL]” for elements that need to be internally managed as C elements. Internally, new forms are created for module, pointer, array procedure and record declared with "[CDECL]”. All basic Oberon types (CHAR, BYTE, BOOLEAN, SHORTINT (16 bits), INTEGER (32 bits), LONGINT (64 bits)) are the same as their equivalent in C. SET is mapped to C 32bits integer for bit-wise manipulations (0: LSB, 31: MSB). The ESP32 is using little-endian for memory addressing. A CModule is the equivalent of a header file in C. No code is produced so no statements are allowed in a CModule. All elements in a CModule are C related, so the use of [CDECL] for array, record, pointer and procedure is induced. A CModule can import other CModules. A CRecordType is the equivalent of a C struc. No RECORD extension is allowed. C Pointers can be declared to point to any simple types and C array, C record, C pointer and C procedure. They cannot be initialized through NEW() but can be initialized through assignation. C Array can be declared to point to any simple types and C array, C record, C pointer and C procedure. C Procedures don’t generate name mangling as for GCC and accept only parameters that are compatible (so no Oberon array, record, pointers and procedures but their [CDECL] equivalent). Guy

6 8

Re: [Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)
by Guy T. 30 Apr '20

30 Apr '20

J. My point is still valid. Selecting a kernel like the Linux one would be a good starting point to get all compatible linux hardware readily available for the Oberon OS. The linux kernel interface can then be used as the hardware abstraction for other integrations like specific chips. You then create the specific limited “kernel” in line with the specifications of the chip manufacturer. Guy >August: >Gcc is a big beast and full of deceit, but there are an awful lot of people >working on it. As a result Gcc generally knows about the latest hardware >available. Also crosscompiler tool chain building is pretty well >standarized. So provided it has the input language you want to use, you >generally can rig up a tool chain almost semi automatically. It just takes >some time recompiling the beast and the utilities. > >Guy: >Linux on a fast Arm chip works reasonably well, but for slow Arm >controllers and small fry a bare metal solution works much much better. >For hi level peripherals one can use the manufacturer provided libraries >via a binding if needed. Just as you are trying to do, except that in your >case the library is proprietary. > >J. > >On Thu, 30 Apr 2020, 23:29 Guy T., <turgu666 at gmail.com> wrote: > >> I’m following this thread with great interest… I was not expecting this >> but it is a very interesting discussion. >> >> For me, the fundamental question is: What is the community trying to >> achieve? >> >> Some partial answers: >> >> - Attract other peoples in the realm of Project Oberon and/or the Oberon >> language. >> - Continue the development of Project Oberon in a niche RISC5/fpga based >> environment. >> - Extend the Project Oberon to get it run on many different hardware >> platforms. >> - Extend the Project Oberon to supply other useful tools to the end user. >> - Other aspects (like convergence of Oberon dialects, etc.) >> - All of the above >> >> My current personal requirement is to use the Oberon language as a mean to >> develop IOT applications on a chip that was not looked at by the community >> up to now. At first, I expected to use it in a “bare metal” manner, but I >> found impossible to do without taking into account the complexity/lack of >> openness of some hardware related aspects of the targeted chip (ESP32) and >> the need to interface the de-facto framework. That framework (ESP-IDF) can >> be seen as an abstraction layer to the hardware. >> >> I would like to see the Oberon OS available on other platforms than the >> RISC5, not because it’s not a nice idea, but it limits the availability of >> a functioning platform as the hardware is rather limited in availability. >> For sure, there is the RISC5 emulator that can be used on many platforms, >> but I would prefer to see it runs as a main alternative to >> Windows/Linux/Whatever. Getting it run on a very cheap platform like the >> Raspberry Pi would be a bonus. It can help attract peoples to the community. >> >> To limit the effort of porting the Oberon Project to other platforms, >> abstracting the hardware is a key aspect, both for the OS and for the >> compiler. Both aspects need to be resolved. Building an abstraction layer >> from scratch would be an important challenge. Think about USB, Ethernet, >> WiFi, Disks Format, etc. The compiler is the easiest portion of porting the >> project, as long as the community converge to a solution. >> >> A first step toward abstracting the hardware could be to use the Linux >> kernel. Just the kernel, and then build on top of it. You then gain all the >> drivers for almost every piece of kit available, transforming the OS only >> once. For the compiler, depending on the choice taken, GCC and its >> dependencies would be also required. >> >> But first, there is a need to converge toward a vision to where, as a >> community, you/we see the future of this project. >> >> Cheers! >> >> Guy

1 0

Re: [Oberon] Interfacing with Foreign Systems
by Chris Burrows 30 Apr '20

30 Apr '20

Before even thinking about embarking on a major project like that I would recommend spending a few months experimenting with GNU Modula-2 (a frontend to GCC) to get an idea of the effort involved in such an exercise and to gain some hands-on experience of how useful the end-product might be. http://nongnu.org/gm2/download.html This work has been actively maintained by Gaius Mulley at the University of Glamorgan for many years now. The Modula-2 mailing list archives are evidence of this: https://lists.nongnu.org/archive/html/gm2/ He has published some related papers on his website. e.g. “A report on the progress of GNU Modula-2 and its potential integration into GCC” http://floppsie.comp.glam.ac.uk/ Regards, Chris Burrows CFB Software https://www.astrobe.com From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Jan de Kruyf Sent: Thursday, 30 April 2020 8:07 AM To: ETH Oberon and related systems Subject: Re: [Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon) guy, when I was young, and still thinking girls were stupid, I also did a hacked Oberon compiler for some micro controller. It was a wonderful learning experience, but although the end result worked, I now would be ashamed to show it. It was ultimately a one off for a one off job. Since then I have learned that girls are actually quite nice and worthwhile to spend some time on, while computer fashions change like the weather. Now for the bigger picture after this digression: As you also did find out, I guess: Oberon is a niche language sitting somewhere in an obscure corner. I maintain that one of the causes is that there is no compiler like gcc that has an oberon front end but that could have many different back ends. (Joerg does not agree with me I know 🙄) If we would stick our heads together and see if an Oberon frontend to gcc is manageable then Oberon becomes a useful tool for many embedded controllers since there are already many back-ends. And the building of a toolchain for cross-compilation is a well documented task, I have done it in Ada. A binding with the hardware / libraries of a new controller can then be whipped up in a matter of days. What you are proposing has been done in the past. People have constructed Oberon to C translators (but without modifying the language), but for one reason or another none of those made it into a productive tool that is used much. Lack of a well documented way to use foreign libraries and lack of an easy debugging mechanism come to mind. hope this stimulates your grey matter a bit. j. On Wed, Apr 29, 2020 at 2:45 PM Guy T. <turgu666(a)gmail.com <mailto:turgu666@gmail.com> > wrote: The approach I’ve taken so far is very similar to the "Oberon-2 Programming with Windows”. Here is the modifications to the language I’ve done (from the syntax definition of Oberon-07): Module = OberonModule | CModule. OberonModule = MODULE ident ";" [ImportList] DeclarationSequence [BEGIN StatementSequence] END ident "." . (* No change here *) CModule = MODULE "[" CDECL "]" ident ";" [ImportList] CDeclarationSequence END ident "." . CDeclarationSequence = DeclarationSequence = [CONST {ConstDeclaration ";"}] [TYPE {TypeDeclaration ";"}] [VAR {VariableDeclaration ";"}] {CProcedureDeclaration ";"}. ArrayType = ARRAY ["[" CDECL "]"] length {"," length} OF type. PointerType = POINTER ["[" CDECL "]"] TO type. ProcedureType = PROCEDURE ["[" CDECL "]"] [FormalParameters]. ProcedureDeclaration = OberonProcedureDeclaration | CProcedureDeclaration. OberonProcedureDeclaration = ProcedureHeading ";" ProcedureBody ident. (* No change here *) CProcedureDeclaration = CProcedureHeading ";" . CProcedureHeading = PROCEDURE ["[" CDECL "]"] identdef [FormalParameters]. RecordType = OberonRecordType | CRecordType. OberonRecordType = RECORD ["(" BaseType ")"] [FieldListSequence] END. (* No change here *) CRecordType = RECORD ["[" CDECL "]"] [FieldListSequence] END. —— The only change to the syntax is the use of a "[CDECL]” for elements that need to be internally managed as C elements. Internally, new forms are created for module, pointer, array procedure and record declared with "[CDECL]”. All basic Oberon types (CHAR, BYTE, BOOLEAN, SHORTINT (16 bits), INTEGER (32 bits), LONGINT (64 bits)) are the same as their equivalent in C. SET is mapped to C 32bits integer for bit-wise manipulations (0: LSB, 31: MSB). The ESP32 is using little-endian for memory addressing. A CModule is the equivalent of a header file in C. No code is produced so no statements are allowed in a CModule. All elements in a CModule are C related, so the use of [CDECL] for array, record, pointer and procedure is induced. A CModule can import other CModules. A CRecordType is the equivalent of a C struc. No RECORD extension is allowed. C Pointers can be declared to point to any simple types and C array, C record, C pointer and C procedure. They cannot be initialized through NEW() but can be initialized through assignation. C Array can be declared to point to any simple types and C array, C record, C pointer and C procedure. C Procedures don’t generate name mangling as for GCC and accept only parameters that are compatible (so no Oberon array, record, pointers and procedures but their [CDECL] equivalent). Guy -- Oberon(a)lists.inf.ethz.ch <mailto:Oberon@lists.inf.ethz.ch> mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

3 3