April 2019 - 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

Oberon on ULX3S
by Goran Mahovlić 04 May '19

04 May '19

Hi to all, For long time we are working on ULX3S FPGA board. http://radiona.org/ulx3s/ And a few days ago we got Oberon on ULX3S https://twitter.com/GMahovlic/status/1122089514070171648 Most of the work was done before by Valentin Angelovskifor his fleaFPGA board! EMARD just adjusted few things needed for Oberon to work on our board... EMARD is still trying to get keyboard and mouse working... We are currently in process of ordering next batch of boards so if there is interest just drop me a mail to ulx3s.fpga(a)gmail.com Radiona is just producing 85F boards with 64Mb SDRAM and ESP32 onboard. But Oberon works on 12F boards that we have available almost all the time. And for the last I have submitted this board to hackady prize so if you are there give us a like. We are currently at 3. place! https://hackaday.io/project/159108-ulx3s-powerful-ecp5-board-for-open-sourc… Goran, Radiona

2 2

PO2013 - System.CloseTrack / System.ExtendDisplay
by Andreas Pirklbauer 02 May '19

02 May '19

> Now mark viewer3 and call System.CloseTrack > - It closes viewer 3 and grown viewer 2 and restores viewer 1 and 2 Ah right. It actually does *more* than “just" the equivalent of System.Close viewer 3 (as alluded to earlier): it also closes all viewers opened *on top* of the grown viewer 2 as well -> so an entire stack of viewers “above” the grown viewer is closed in a single step. A neat feature.. but rarely used (I suspect?), as the average user doesn’t necessarily think in stacked 3-dimensional window layouts.

4 4

Re: [Oberon] Unreferenced/unused code in Project Oberon 2013
by Артур Ефимов 28 Apr '19

28 Apr '19

Curve* = POINTER TO CurveDesc; CurveDesc* = RECORD (Graphics.ObjectDesc) kind*, lw*: INTEGER END ; VAR method*: Graphics.Method; If you make these objects unexported, noone will be able to extend the code for Curves.

1 0

Unreferenced/unused code in Project Oberon 2013
by Andreas Pirklbauer 28 Apr '19

28 Apr '19

> -Kernel: It’s not wise to delete StackSize. If you want to improve, > rather use StackSize in Modules instead of using a constant there. > > br > Jörg Exactly. One should not flush the baby with the bathtub. E.g. one can change Kernel.Init from: PROCEDURE Init*; BEGIN Files.Init; MTOrg := SYSTEM.REG(MT); SYSTEM.GET(16, AllocPtr); SYSTEM.GET(20, root); SYSTEM.GET(24, limit); DEC(limit, 8000H) END Init; to: PROCEDURE Init*; BEGIN Files.Init; MTOrg := SYSTEM.REG(MT); SYSTEM.GET(16, AllocPtr); SYSTEM.GET(20, root); limit := Kernel.stackOrg - Kernel.stackSize END Init;

1 0

Unreferenced/unused code in Project Oberon 2013
by Michael Schierl 27 Apr '19

27 Apr '19

Hello, I used some scripts to identify unreferenced code (after stumbling upon some unused variables in TextFrames), and was surprised how much code I could remove without affecting the system at all... (I also removed System.ExtendDisplay, as that one is of no use in Project Oberon, but apart from that I tried not to remove any command procedures.) Does anyone know if that code is there to be useful in the future, or did Prof. Wirth just not yet find the time to finish his software (which, if I recall correctly, is not finished when there is nothing left to add, but nothing left to take away)? Here is a diff: https://github.com/schierlm/OberonXref/blob/remove-unreferenced-code/remove… And here is a side-to-side view: https://github.com/schierlm/OberonXref/commit/e49dddb57d076ef6a256496949d15… Regards, Michael

3 3

The Oberon System now runs on the Radiona ULX3S
by rochus.keller＠bluewin.ch 26 Apr '19

26 Apr '19

As I told you I ordered an ULX3 (see https://radiona.org/ulx3s/ ) a week ago and thought it would give a nice vehicle to experiment with Lola-2, RISC5 and the Oberon System only using an open source toolchain. I also told Goran Mahovlić who is my contact at Radiona about my intentions. As it seems they liked the idea to migrate the Oberon System to their board and immediately started to do it themselves. He informed me today that they already managed to boot the Oberon System on the ULX3S 12F version. It's still work in progress, but you can have a look at https://github.com/emard/oberon and https://github.com/emard/oberon/commit/4e75736a22fdf01c0335e9fd73f13465f4d7… if you're interested. I will try to run it as soon as the ULX3S arrives. Best R.K.

3 2

Lola TS [WAS Re: Assumed issue in the Lola-2 compiler]
by rochus.keller＠bluewin.ch 25 Apr '19

25 Apr '19

@ Paul Reed Thanks for your feedback. >> I agree it's tempting but I was rather glad I didn't change the TS to >> generate inline 'z expressions, when I came across a toolchain (Clifford >> Wolf's IceStorm tools for the Lattice iCE40) which didn't implement >> tri-state properly from the Verilog. I hoped it was fixed in nextpnr. The issue was primarily that arachne-pnr couldn't handle the _TBUF_ cells generated by yosys. I will check that. Of course we can implement our own module but I think it's a pity if the compiler assumes an implicit module dependency. >> Delete the following IF in LSC.Statement >> IF z # x THEN x.a := z.b; x.val := 1 END Please also note that Jörg Straube informed me that his fix is not the final solution and there are still other issues in the Oberon code of the Lola compiler. I started to develop my own Lola-2 compiler and will also implement a Verilog generator (not only a ILANG generator) to be less dependent on the Oberon version. Best R.K.

2 1

Re: [Oberon] Assumed issue in the Lola-2 compiler
by rochus.keller＠bluewin.ch 24 Apr '19

24 Apr '19

Meanwhile I could also integrate the other fix by Jörg Straube (see http://lists.inf.ethz.ch/pipermail/oberon/2019/013320.html ) and also fixed two issues in the Risc5 Lola files. See https://github.com/rochus-keller/Lolac/tree/master/Original and https://github.com/rochus-keller/Lolac/tree/master/Examples/RISC5_original There seems still to be an issue with declarations of 2D arrays in the Lola-2 compiler; see https://github.com/rochus-keller/Lolac/blob/1cac988503e6b081619848a1fe11b96… The same issue is also visible in the Lolac version generated with the Vishap compiler from the Oberon files. I also would like to discuss whether there is a way to avoid using a Xilinx specific module for TS() in the Verilog code generated by the Lola-2 compiler, see e.g. https://github.com/rochus-keller/Lolac/blob/1cac988503e6b081619848a1fe11b96… Best R.K.

3 3