March 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): BootManager.
by peter＠easthope.ca 01 Apr '20

01 Apr '20

Pablo, > I think that a copy of Oberons legacy codes in github, gitlab and > sourceforge could be convenient in order to use it as voluntary or > community archives. Thanks for your reply. > As for Wikibooks, I don't know if we could use it also for archiving > purposes of legacy codes, but at least it could be cited as text in the > pages like an appendix with the code in some printed books. After about 8 hours of editing, Andre's Boot Manager document is now available here. Editing was required to recover original format and repair links. https://en.wikibooks.org/wiki/User:PeterEasthope/sandbox#Summary_of_features In my sandbox until ready for the Oberon book. If you can spare the time to read it, any comments will be very welcome. Thanks! ... P. -- https://en.wikibooks.org/wiki/Medical_Machines https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140 Bcc: peter at easthope. ca

3 2

FW: Integrating the Arm Cortex-M3 in a Xilinx FPGA
by Skulski, Wojciech 31 Mar '20

31 Mar '20

FYI. This may interest Chris. In principle, his compiler may lead into an alternative FPGA Oberon System running on the M3 core. https://www.doulos.com/content/events/Arm_Cortex-M3_Xilinx_FPGA_xlx.php ________________________________________ From: Xilinx, Inc. [xilinxmail(a)xilinx.com] Sent: Tuesday, March 31, 2020 12:01 PM To: Skulski, Wojciech Subject: Integrating the Arm Cortex-M3 in a Xilinx FPGA WEBINAR Integrating the Arm Cortex-M3 in a Xilinx FPGA [Xilinx Doulos ARM Cortex-M3 Webinar] April 8, 2020 | 10 ‒ 11am PDT – Accessible World-Wide The combination of the widely acclaimed Arm® Cortex®-M MCU architecture with the performance of a Xilinx® FPGA provides more flexibility and greater scope for innovation in the creation of application-optimized designs. In this webinar, we will examine the Cortex-M3 IP block and discuss its integration inside a Xilinx FPGA. You will learn about: * The two main system buses, their use model and restrictions * The operations of the Nested Vectored Interrupt Controller (NVIC) and its interaction with a Wakeup Interrupt Controller (WIC) * The memory management operations along with invasive and non-invasive debugging features of the core Xilinx Authorized Training Provider Doulos presents this webinar with interactive Q&A for the attendees. https://www.doulos.com/content/events/Arm_Cortex-M3_Xilinx_FPGA_xlx.php

2 1

Re (2): BootManager.
by peter＠easthope.ca 24 Mar '20

24 Mar '20

From: Liam Proven <lproven(a)gmail.com> Date: Mon, 23 Mar 2020 14:04:17 +0100 > Hmmm. Perhaps not the ideal home, but yes, Wikibooks would suffice. Liam, thanks for replying. What would be a be a better or ideal location for the document? Source and executable are distinct questions of course. 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

3 2

Re: [Oberon] An Oberon-07 compiler for the ESP32
by Guy T. 24 Mar '20

24 Mar '20

> It is too soon for me to tell if it will be compatible with the existing ESP-IDF framework and FreeRTOS. I’m dedicating all my free time to get the compiler working properly, including the garbage collector. I’m currently building a kind of compliancy test that runs on a chip to raise my level of confidence on the compiler. Everything I’ve done for now is to have Project Oberon Compiler and part of the Kernel module ported to the ESP32. My aim is to see how far a “bear metal” programming environment can be achieved on this chip. > > One aspect for which I will have to work on after will be the WiFi integration, for which I will have to integrate part of the ESP-IDF framework. I expect to have to change some aspects of the underneath compiler architecture, but not that much. If somebody is interested to look at it… :-) > > When I started this project, it was more of an experiment to better understand the Xtensa instruction set. I was amazed how fast I was able to come with a (sort of) working compiler after only three weeks of effort. But now, debugging and compliancy tests is a must to ensure everything is Ok and this takes a lot of time to built. Thanks to Niklaus Wirth and all people involved on the Project Oberon! > > Guy Well… In my last message, I made an interesting typo… it’s not “bear metal” but “bare metal”… sorry for the animals!! Guy

1 0

Re: [Oberon] An Oberon-07 compiler for the ESP32
by Guy T. 24 Mar '20

24 Mar '20

> Hi: > > this is wonderful. Is there a chance that this project will accommodate the application code developed by Parallax for their ESP32 module? Parallax developed the WebSockets interface, micro web server, and the micro file system for the embedded flash. > > https://www.parallax.com/search?search_api_views_fulltext=32420 <https://www.parallax.com/search?search_api_views_fulltext=32420> > > Thank you, > Wojtek Hello Wojtek, The Parallax module seems to be using the ESP8266, not the ESP32 (unless there is another product I’ve not seen at the URL). It’s a bit different processor. The generated code is not compatible. Cheers, Guy

1 0

Re: [Oberon] An Oberon-07 compiler for the ESP32
by Guy T. 24 Mar '20

24 Mar '20

> @ Guy T. > > Nice project, thanks. How does it integrate with ESP-IDF and FreeRTOS? How about the GC and threads? > > Another approach could be an Oberon front end for GCC or LLVM (the latter also has an Xtensa back end, see https://github.com/espressif/llvm-project <https://github.com/espressif/llvm-project>. > > Best > R. It is too soon for me to tell if it will be compatible with the existing ESP-IDF framework and FreeRTOS. I’m dedicating all my free time to get the compiler working properly, including the garbage collector. I’m currently building a kind of compliancy test that runs on a chip to raise my level of confidence on the compiler. Everything I’ve done for now is to have Project Oberon Compiler and part of the Kernel module ported to the ESP32. My aim is to see how far a “bear metal” programming environment can be achieved on this chip. One aspect for which I will have to work on after will be the WiFi integration, for which I will have to integrate part of the ESP-IDF framework. I expect to have to change some aspects of the underneath compiler architecture, but not that much. If somebody is interested to look at it… :-) When I started this project, it was more of an experiment to better understand the Xtensa instruction set. I was amazed how fast I was able to come with a (sort of) working compiler after only three weeks of effort. But now, debugging and compliancy tests is a must to ensure everything is Ok and this takes a lot of time to built. Thanks to Niklaus Wirth and all people involved on the Project Oberon! Guy

1 0

Re: [Oberon] An Oberon-07 compiler for the ESP32
by rochus.keller＠bluewin.ch 23 Mar '20

23 Mar '20

@ Guy T. Nice project, thanks. How does it integrate with ESP-IDF and FreeRTOS? How about the GC and threads? Another approach could be an Oberon front end for GCC or LLVM (the latter also has an Xtensa back end, see https://github.com/espressif/llvm-project) Best R. _______________________________ From: Guy T. Sent on: Mon, 23 Mar 2020 13:31:52 +0100 To: oberon(a)lists.inf.ethz.ch Cc: Subject: [Oberon] An Oberon-07 compiler for the ESP32 Hello all, Just to let you know that I'm in the process of building an Oberon-07 compiler for the ESP32 chip, based on the Project Oberon compiler. Still a work in progress but a good part of the compiler is working well. It took me around 4 weeks (full time effort) to develop and I'm in the debugging phase since 3 weeks (part time). You can find it here: https://github.com/turgu1/esp32-oberon-compiler Cheers! Guy

2 1