December 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

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

QEMU target implementation for Oberon RISC architecture
by Charles Perkins 01 Jan '20

01 Jan '20

This is to let you all know about a fork of QEMU (a very fast emulator with lots of features) introducing the Oberon RISC architecture. https://github.com/io-core/qemu-risc6 It is unfinished and I probably should have waited to announce it but the new year starts soon and I just want to share some pretty (to me) pictures. As it says in the readme on the github page, the target is named risc6 to avoid confusion with the already existing riscv target in qemu and because in one communication (An Update of the RISC5 Implementation <https://inf.ethz.ch/personal/wirth/ProjectOberon/RISC5.Update.pdf>) Professor Wirth defines module RISC6 to introduce interrupts into the architecture. I intend to update the readme with build instructions and binaries that can be simply downloaded, etc. Happy Hacking, Chuck

8 11

Re: [Oberon] QEMU target implementation for Oberon RISC architecture
by Jörg 01 Jan '20

01 Jan '20

All Just to refine my idea. The second byte of the MOV’ instruction could identify the emulator as follows: Peter de Wachter’s emulator could return 50H (ASCII “P”) Andreas Pirklbauer’s emulator could return 41H (ASCII “A”) Chuck Perkin’s emulator could return 43H (ASCII “C”) Michael Schier’s emulator could return 4DH (ASCII “M”) Roel de Jong’s emulator could return 52H (ASCII “R”) I know this method does not scale. But to give the first brave emulator programmers one letter of credit ☺ And remember: it’s only an idea… Happy New Year to all of you. Jörg Von: Oberon <oberon-bounces(a)lists.inf.ethz.ch> im Auftrag von Jörg <joerg.straube(a)iaeth.ch> Antworten an: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Datum: Dienstag, 31. Dezember 2019 um 09:51 An: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Betreff: Re: [Oberon] QEMU target implementation for Oberon RISC architecture All Sorry, I made a typo. The correct identification code should look like this: cpu := SYSTEM.H(2019) MOD 100H; IF cpu = 53H THEN (* RISC5: with interrupts + floating-point, 31.8.2018 *) ELSIF cpu = 54H THEN (* RISC5a: no interrupts, no floating-point, 1.9.2018*) ELSIF cpu = 0A0H THEN (* RISC0, 26.12.2013 *) END ; First of all, the CPU version identification is an undocumented feature. So only NW knows, if it will be supported in the future. Perhaps we as Oberon community can agree on how emulators shall identify itself. I see four thinkable ways Return one of the values above, as the real FPGA HW would do. Be totally transparent to the Oberon code. Return another value, so the Oberon code might find out that it’s running on an emulator if he wants to do so Use a few of the 20 unused bits in the instruction, currently set to 0. This has the benefit that the CPU version is still one of the defined ones, and we can detect the CPU feature set foreseen by NW. We still have the possibility to detect on what emulator this CPU is implemented. Define a new (still unused) instruction to just return the emulator version. My recommendation would be: c). Just as an idea: use the second lowest byte to identify the emulator. As example: SYSTEM.H(2019) DIV 100H MOD 100H would identify the emulator. br Jörg -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

2 2

QEMU target implementation for Oberon RISC architecture
by Andreas Pirklbauer 31 Dec '19

31 Dec '19

> cpu := SYSTEM.H(2019) MOD 80H; > IF cpu = 53H THEN (* RISC5: with interrupts + floating-point, 31.8.2018 *) > ELSIF cpu = 54H THEN (* RISC5a: no interrupts, no floating-point, 1.9.2018*) > ELSIF cpu = A0H THEN (* RISC0, 26.12.2013 *) > END ; BTW, my system (in an emulator) returns cpu = 50H, i.e. none of the above values.

2 1

FPGA RISC memory interfacing
by Andreas Pirklbauer 26 Dec '19

26 Dec '19

> I noticed that Oberon System frequently freezes on one Pepino which we > have. I have not identified any pattern. Sometimes it works for days, and > sometimes it freezes after a mouse click on a command like the Hilbert curve. It could also (potentially!) have to do with module unloading. If module Hilbert overwrites a previously released module block, which is however still referenced by other loaded modules or data structures (e.g., via type references or procedure variable references), the entire system may become unstable at that moment (recall that FPGA Oberon is inherently unsafe with respect to module unloading).

3 4

FPGA RISC memory interfacing
by Andreas Pirklbauer 26 Dec '19

26 Dec '19

> There was also is a bug in the allocator (dubbed "memory alligator” here > on the mailing list), which I am not sure whether it is already fixed in the > official sources. A failed allocation can cause the linked list of free memory > segments to get corrupted, which may result in a freeze or other corruption > related artifacts later. As an FYI: On my system, detecting the double trap only works with the “memory alligator” fix also implemented in module Kernel, for example as follows: PROCEDURE GetBlock128(VAR p: LONGINT); VAR q: LONGINT; BEGIN IF list1 # 0 THEN p := list1; SYSTEM.GET(list1+8, list1) ELSE GetBlock(q, 256); IF q > 0 THEN SYSTEM.PUT(q+128, 128); SYSTEM.PUT(q+132, -1); SYSTEM.PUT(q+136, list1); list1 := q + 128 END ; p := q END END GetBlock128; PROCEDURE GetBlock64(VAR p: LONGINT); VAR q: LONGINT; BEGIN IF list2 # 0 THEN p := list2; SYSTEM.GET(list2+8, list2) ELSE GetBlock128(q); IF q > 0 THEN SYSTEM.PUT(q+64, 64); SYSTEM.PUT(q+68, -1); SYSTEM.PUT(q+72, list2); list2 := q + 64 END ; p := q END END GetBlock64; PROCEDURE GetBlock32(VAR p: LONGINT); VAR q: LONGINT; BEGIN IF list3 # 0 THEN p := list3; SYSTEM.GET(list3+8, list3) ELSE GetBlock64(q); IF q > 0 THEN SYSTEM.PUT(q+32, 32); SYSTEM.PUT(q+36, -1); SYSTEM.PUT(q+40, list3); list3 := q + 32 END ; p := q END END GetBlock32;

1 0

FPGA RISC memory interfacing
by Andreas Pirklbauer 24 Dec '19

24 Dec '19

> I started Oberon System on Pepino. I executed Hilbert.Draw and then > Sierpinski.Draw. The system is still running, but the display was pretty > corrupted with pieces of curves displayed in wrong places. Then it’s almost certainly not related to module unloading (maybe the freezing was at one point though).

1 0

Re: [Oberon] Sherlock Holmes looking for ben
by Jörg 24 Dec '19

24 Dec '19

Wojtek ben (=byte enable) is TRUE (1) if you want to access a byte and FALSE (0) if it is a word access. When you access your memory chip, you have to convert these boolean/logical values to active low or active high depending on the meaning of the control lines of your chip. For the memory chip used by ProjectOberon, the real memory access looks like this (RISC5Top.v): assign SRce0 = ~(~ben | ~adr[1]); assign SRce1 = ~(~ben | adr[1]); assign SRbe0 = ~(~ben | ~adr[0]); assign SRbe1 = ~(~ben | adr[0]); br Jörg Am 19.12.19, 01:38 schrieb "Oberon im Auftrag von Skulski, Wojciech" <oberon-bounces(a)lists.inf.ethz.ch im Auftrag von skulski(a)pas.rochester.edu>: All: trying to decipher the firmware I am now puzzled with the individual byte access logic in RISC5 and RISC5top. For the individual byte access, the processor is outputting "ben" described in PO.Computer page 2 as follows: "ben indicates a byte (rather than word) access". There is no further information in PO.Computer whatsoever. There is no truth table. Using my ingenuity I am guessing "ben" is active LOW because otherwise it would have been named "be". But this is not a strong basis to be sure. Exploring the open source did not bring definite knowledge. Namely, inside RISC5.v "ben" was made wonderfully clear: assign ben = p & ~q & v & ~stallX & ~stall1; // byte enable where both "p" and "q" are clear to everyone: assign p = ins[31]; assign q = ins[30]; where "ins" is obvious to at least some students, as follows: assign ins = PMsel ? pmout : IR; // decoding After exploring all this great information I am not sure whether "ben" is active LOW or HIGH, and where to find the answer. Does anyone know? Thanks! Wojtek -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

5 14