February 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

PO2013 - Real time measurement
by Tomas Kral 23 Apr '19

23 Apr '19

Hi, I wish to do some real time input from basic sensors. This discipline is well established with so called home automation, developed through Arduino project, see MySensors lib, etc. [a] Arduino can do A/D conversions for Oberon while it can talk over WiFi, the same WiFi, PO2013 was designed with, more sensors can be linked in a HUB. [b] PIC processors can also do A/D conversion. PIC can possibly interconnect through GPIO, while I cannot see an easy way to add more devices to the hub (* multiplexing GPIO input???*). It also has some leverage in NW's PICL project. Both options require some more studying and understanding on my part. Generally what is your experience, recommendations to pursue [a], [b] for PO2013? Many thanks -- Tomas Kral <thomas.kral(a)email.cz>

9 52

FPGA - System Clock advance
by Tomas Kral 20 Mar '19

20 Mar '19

Hi, Getting ready for time ticks, while toying with this code. PROCEDURE Time*; VAR s, dt, hr, min, sec: INTEGER; BEGIN s := Kernel.Time() (*milis*) DIV 1000; (*seconds*) Texts.WriteInt(W, s, 6); hr := s DIV 3600; min := (*s - hr*3600*) s MOD 3600 DIV 60; sec := s MOD 60; Texts.WriteInt(W, hr, 6); Texts.WriteInt(W, min, 6); Texts.WriteInt(W, sec, 6); s := hr*3600 + min*60 + sec; Texts.WriteInt(W, s, 6); (*sanity check*) dt := hr*1000H + min*40H + sec; (*system date time*) (* Kernel.SetClock(dt); *) Texts.WriteClock(W, dt); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END Time; Now, in `Oberon.Mod' we have `GC' task getting awaken every 1000 ms = 1 sec. That could be used to advance system date time as well, using some of the code above. The above code itself however consumes some time delta, not sure if need be compensated for? Also, we could introduce a new message type for time updates, and broadcast by `Viewers.Broadcast()', so any code can poll the Kernel.Clock() by a given period? -- Tomas Kral <thomas.kral(a)email.cz>

4 11

IMPORT Modules: why does order matter?
by Till Oliver Knoll 02 Mar '19

02 Mar '19

Hello, It seems that with the Project Oberon 2013 compiler the order of imported modules seems to matter now (at least in „Oberon Core“, as available in the Mac App Store). That was definitively not the case with OberonV4. E.g. when I have: IMPORT Oberon, ..., Display; I get an „invalid import order“ (or similar) compile error, which I have to „fix“ with: IMPORT Display, ..., Oberon; (Or the other way around - just for illustration). I haven‘t yet figured out the „rule“ of the correct ordering, but I suspect it has to do with the Oberon Module hierarchy, or „lower modules first“. So far I just shuffled the imports around, until it compiles. Is that the expected behaviour of the compiler? If so (out of pure curiosity): what could be the reasoning behind that? Does it simplify the compiler by, say, 3 KByte worth of source code? :) Or is there really a (compiler) technical reason which significantly improves „dependency parsing“? Or does the compiler simply want me to know Oberon‘s module hierarchy by heart? (Mind you, I am not talking about the order of compilation of my modules; that I know. I am really referring to the order of a single import statement). Thanks, Oliver

3 3

Question on ORG.SaveRegs / ORG.RestoreRegs in the FPGA Oberon compiler
by Andreas Pirklbauer 02 Mar '19

02 Mar '19

As a purely pedagogical addendum: A possible student exercise would be to rewrite ORG assuming *no* procedure variables existed in the language: PROCEDURE PrepCall*(VAR x: Item; VAR r: LONGINT); BEGIN (*x.type.form = ORB.Proc*) r := RH; IF RH > 0 THEN SaveRegs(RH); RH := 0 END END PrepCall; PROCEDURE Call*(VAR x: Item; r: LONGINT); BEGIN (*(x.mode = ORB.Const) & (x.type.form = ORB.Proc)*) IF x.r >= 0 THEN Put3(BL, 7, (x.a DIV 4)-pc-1) ELSIF pc - fixorgP < 1000H THEN Put3(BL, 7, ((-x.r) * 100H + x.a) * 1000H + pc-fixorgP); fixorgP := pc-1 ELSE ORS.Mark("fixup impossible") END ; IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0 ELSE (*function*) IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ; x.mode := Reg; x.r := r; RH := r+1 END END Call;

2 1

System-7 - Math popular consts
by Tomas Kral 01 Mar '19

01 Mar '19

Hi, Just discovered `Math.mod', such a tiny module! I wish to add two consts to it. pi = 3.14159265 e = 2.71828182 Float format on risc is x = 1.m * 2^(e-127) bit 0: sign, bits 1- 8: e, bits 9-31: m I believe binary mantisa roughly corresponds to 8 decimal digits. Now, how to code the consts to make most of the given mantisa? -- Tomas Kral <thomas.kral(a)email.cz>

4 6

Module Display: ReplPatternC (with clipping)?
by Till Oliver Knoll 28 Feb '19

28 Feb '19

Hello all, As indicated in my first post I am porting our "GigaDraw" exercise that we wrote as an exercise during the "Systemprogrammierung" in winter semester 98/99. I stumbled over missing functions in module Display, specifically the copy/replicate pattern functions with their "clipping" variants, as they were available in OberonV4 (I think) at the time. E.g. as still found here: https://github.com/Spirit-of-Oberon/ProjectOberonV4/blob/master/Display.Def For instance this function dodes not exist anymore in the current Display Module: PROCEDURE ReplPatternC*(F: Frame; col: INTEGER; pat: Pattern; x, y, w, h, xp, yp, mode: INTEGER); END ReplPatternC; The only discussion i found in the list archive around "ReplPattern" is here: https://lists.inf.ethz.ch/pipermail/oberon/2018/012119.html That discussion seems to confirm that the "clipping variants" are indeed not available anymore (and that discussion mostly is about "4bit displays" and how to write "concurrent display drivers" implementing Module Display). When I quickly replace my "line drawing code" which for instance is (in its original form): Display.ReplPatternC(msg.f, line.col, Display.grey0, u, v, w, h, u, v, Display.replace) with the corresponding call like Display.ReplPattern(line.col, Display.grey, u, v, w, h, Display.replace) then I do get a dotted line, but as expected I scribble all over the screen, especially across Frame boundaries (when I move the line near the Frame border). (And yes, apparently in the first "Lines" module of ours we were only able to either draw horizontal or vertical lines - no Bresenham algorithm yet ;)). So my question: is there a "higher level" drawing module available (I am using "Oberon Core", as available in the Mac App Store), possibly in other Oberon variants these days (e.g. "Experimental Oberon")? Or is one supposed to write your own "Drawing API", doing the "bit fiddling" clipping yourself? Sorry for the noob question or if this has been asked before, but I did not find much in the archive (except the above discussion). And yes, a pointer to a RTFM is perfectly fine :) Best regards, Oliver

3 3

Re (2): Oberon-7 - Circle Segments
by peter＠easthope.ca 27 Feb '19

27 Feb '19

Hello Thomas, Have you looked at the clocks in S3 and in A2? System.Directory *Clock*.Mod /usr/aos/source/Unix.Clock.Mod /usr/aos/source/Windows.Clock.Mod /usr/aos/source/BIOS.Clock.Mod /usr/aos/source/Oberon.Clocks.Mod /usr/aos/source/BenchClockDrift.Mod /usr/aos/source/Clock.Mod /usr/aos/source/WMClock.Mod 7 files Regards, ... L. -- Message composed and transmitted by software designed to avoid the complication and vulnerability of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 +1 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 6

Re: [Oberon] Re (2): Oberon-7 - Circle Segments
by John R. Strohm 26 Feb '19

26 Feb '19

Can't see it clearly enough to see what is "interesting". If you're expecting the hour hand to be offset from the number, by the minute increment (like a real mechanical clock would), you'll have to run the trig down that level of precision. For example, at 4:30, the hour hand would be halfway between 4 and 5, not sitting on 4, with the minute hand on 6. --- thomas.kral(a)email.cz wrote: From: Tomas Kral <thomas.kral(a)email.cz> To: <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Re (2): Oberon-7 - Circle Segments Date: Tue, 26 Feb 2019 22:29:42 +0100 Hi, I have a gimmick clock, not ticking yet. Something interesting about minute/hour ticks, in the picture minute = ticks 5 of 60 hour = ticks 55 of 60 which is possibly rendered wrong. -- Tomas Kral <thomas.kral(a)email.cz> -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0