March 2018 - Oberon - mailman3.inf.ethz.ch

FPGA - Screen.Mod
by Tomas Kral 26 Oct '18

26 Oct '18

Hi, EDIT (1) I am looking for `Screen.Mod' module (mainly its `Screen.Grub' command) hinted in PO2013 pictures. I have completed early version of `Bitmaps.Mod' supporting basic set of raster operations. I wish to share pictures and code. As we may not post attachments to the forum, I could expose to GitHub, there is also `WikiBook' run by Lyall E. Please advise. Many thanks. -- Tomas Kral <thomas.kral(a)email.cz>

4 15

FPGA Oberon - Definition Module Tool
by thomas.kral＠email.cz 08 Oct '18

08 Oct '18

Hi, I am thinking of a simple tool that could extract definition info from *.Mod and produce respective *.Def file. Definition files can be quickly looked at, to remind a programmer of the interface *.Mod modules export. While on Linux one could use grep $ grep PROCEDURE\ * *.Mod.txt to obtain info at least about procedures, but how about exported types and variables? I am looking for a recommended way how to simply code such a tool, is it a good idea to use `ORP' parser somehow for the task? I prefer to code it simple, does not have to be perfect, but should carry the idea. Tomas

5 11

Project Oberon / MIPS Linux
by Andreas Pirklbauer 24 Mar '18

24 Mar '18

> is now available at http://oberon.wikidot.com . It has a native MIPS32 > compiler. > > Regards, > Peter Thx. It’s well written.

1 0

WIP: Project Oberon / ARM Linux
by Peter Matthias 23 Mar '18

23 Mar '18

Hi all, an untested public version of PO/L is available at http://oberon.wikidot.com Regards, Peter

2 2

Exercise in Text parameter handling.
by peter＠easthope.ca 20 Mar '18

20 Mar '18

From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> Date: Wed, 14 Mar 2018 19:10:54 +0100 IF v.state > 1 THEN (*v is a displayed viewer*) ELSIF v.state = 1 THEN (*v is a filler viewer*) ELSIF v.state = 0 THEN (*v is a closed viewer*) ELSIF v.state < 0 THEN (*v is a suspended viewer*) END OK, thanks. My exercise including "Oberon.MarkedViewer().state > 1" follows. For * marked viewers, distinguishing an original style Text viewer from a Document viewer is by the order of the two Marked evaluations. I have yet to learn how to make the distinction for selected Text. Is a selection in a plain viewer or in a Document viewer? Necessary if I want to open a new viewer of the same style as the original. Any comments about the exercise are welcome of course. Likely I've missed at least one detail. Thanks, ... Lyall E. MODULE ParameterHandling IN Oberon; IMPORT Documents, Oberon, Texts; VAR S: Texts.Scanner; W: Texts.Writer; sel: Texts.Text; beg, end, time: LONGINT; source: CHAR; (* "t" for all Text in a Text viewer, "d" for all Text in a Document viewer, "n" for * parameter following command and no marker displayed, "s" for for Text selected in a Text viewer, "u" for for Text selected in a Document viewer, "o" for ^ parameter following command but no selection, "f" for a named file and "z" for command with no parameter; ParameterHandling.Test ~ . *) (* ParameterHandling.Test * (Marked viewer), ParameterHandling.Test ^ (Text selection), ParameterHandling.Test { <filename> } ~ Named files containing Texts. *) PROCEDURE Test*; BEGIN Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(S); IF S.class=Texts.Char THEN IF S.c="*" THEN (* Viewer marked? *) IF (Documents.MarkedDoc() # NIL) & (Oberon.MarkedViewer().state > 1) THEN source := "d" ELSIF (Oberon.MarkedViewer() # NIL) & (Oberon.MarkedViewer().state > 1) THEN source := "t" ELSE source := "n" END ELSIF S.c="^" THEN (* Text selected? *) Oberon.GetSelection(sel, beg, end, time); (* Is the Text in an original style Text viewer or in a Document viewer? *) IF sel # NIL THEN source := "s" ELSIF FALSE THEN source := "u" ELSE source := "o" END END ELSIF S.class=Texts.Name THEN (* Existing or new file named. *) source := "f" ELSE source := "z" END; Texts.WriteString(W, "source = "); Texts.Write(W, source); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf); IF source = "f" THEN Texts.WriteString(W, "Filename parameter = "); Texts.WriteString(W, S.s); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf); END END Test; BEGIN Texts.OpenWriter(W) END ParameterHandling. Compiler.Compile * ~ ParameterHandling.Test * ParameterHandling.Test ^ ParameterHandling.Test Oberon.ParameterHandling.Mod ~ -- This message was transmitted by software carefully written to avoid the overhead and vulnerability of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Re: Android
by peter＠easthope.ca 18 Mar '18

18 Mar '18

>From PeterMatthias at web.de Sun Jan 28 10:18:57 2018 > Android uses Linux Kernel. OLR/ARM Linux runs, but is not compatible > with Android runtime system. E.g. Android updates the framebuffer > frequently so that OLR output on the framebuffer is overwritten. About six years ago, Inferno ran on Android without Java. The framebuffer is mentioned in the 2nd paragraph here. https://bitbucket.org/floren/inferno/wiki/Home Regards, ... Lyall E. -- This message was transmitted by software carefully written to avoid the overhead and vulnerability of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Re: Android
by peter＠easthope.ca 18 Mar '18

18 Mar '18

>From PeterMatthias at web.de Sun Jan 28 10:18:57 2018 > Android uses Linux Kernel. OLR/ARM Linux runs, but is not compatible > with Android runtime system. E.g. Android updates the framebuffer > frequently so that OLR output on the framebuffer is overwritten. About six years ago, Inferno worked on Android. https://bitbucket.org/floren/inferno/wiki/Home The framebuffer is mentioned in the second paragraph. Regards, ... Lyall E. -- This message was transmitted by software carefully written to avoid the necessity, vulnerability and overhead of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Re: Viewer marking.
by Andreas Pirklbauer 14 Mar '18

14 Mar '18

> Is there a practical way to check whether the Pointer is > in a Text or Document viewer and not in the FillerViewer? IF v.state > 1 THEN (*v is a displayed viewer*) … ELSIF v.state = 1 THEN (*v is a filler viewer*) … ELSIF v.state = 0 THEN (*v is a closed viewer*) … ELSIF v.state < 0 THEN (*v is a suspended viewer*) … END

1 0

Re: Viewer marking.
by peter＠easthope.ca 14 Mar '18

14 Mar '18

Andreas, From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> Date: Tue, 6 Mar 2018 18:21:27 +0100 > If you can modify module Oberon, just add the following procedure > > PROCEDURE PointerOn*(): BOOLEAN; > ... OK, thanks. No problem with that. What about generalizing? Add the check to MarkedViewer? (** Returns the star-marked viewer. *) PROCEDURE MarkedViewer* (): Viewers.Viewer; VAR v: Viewers.Viewer; BEGIN IF PointerOn() THEN v := Viewers.This(Pointer.X, Pointer.Y) ELSE v := NIL END; RETURN v END MarkedViewer; > Perhaps the reason why Sort traps is that Oberon.MarkedViewer > returns the filler viewer, whose fields Viewers.FillerViewer.dsc > and Viewers.FillerViewer.next are both always set to NIL. Another possibility I failed to anticipate. Ideally a command should be bulletproof but that might be impossible. Is there a practical way to check whether the Pointer is in a Text or Document viewer and not in the FillerViewer? Thanks, Lyall E. -- This message was transmitted by software carefully written to avoid the necessity, vulnerability and overhead of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

RiskFive and Use of IP Cores
by jwr＠robrts.net 13 Mar '18

13 Mar '18

In a series of 2017 messages "RISC-5 and Memory", there was an excellent discussion. I wish to add a some comments of my own. In his 5 Oct message posted at http://lists.inf.ethz.ch/pipermail/oberon/2017/011051.html, Wojtek Skulski said (among other good things): "Don't do it yourself. Use Xilinx Core Generator which will interface the hard silicon logic built into Xilinx FPGA banks." "The bottom line: if you want to use high speed DDRx memories at close to their ratings, you cannot achieve it with LOLA-generated Verilog. You need to follow the FPGA manufacturer hard silicon solution, which is provided with their design tools." "But if we want to see V4, S3, or CP running on the FPGA (which are worthy goals!), then we need to tackle the subject matter with full repository of available tools and IP cores." The (original) Project Oberon demonstrated many things, including that it was possible to develop a fully capable system which was small and highly understandable. Project Oberon 2013 extended this demonstration by making even the "hardware" visible and understandable in HDL, as well as portable to new FPGA boards. However, several critical decisions were made to support and favor goals of simplicity, size, and visibility, which it may now be time to move beyond for newer (specialized) implementations. Recall that the PS/2 interface was selected for mouse and keyboard, because the code to support USB would exceed the size of the entire PO2013 Oberon+HDL code. Recall that static ram was selected because implementation of a dynamic ram controller would be highly complex, and that decision also drove the limited total memory available (usually 1Mb) and the initial monochrome display. There were other key choices as well which served to facilitate the proof-of-concept and educational purposes of Project Oberon, which now limit overall system capability. We now HAVE an excellent educational system which is sufficiently small and fully understandable for study, usable for many applications. We now are well positioned to move beyond that point, to more capable, higher-performance systems. Wojtek (and others) want to use Oberon as system software for highly-capable high-performance (hardware) applications. I concur that we now need to take advantage of built-in and available hardware cores, to enable the next set of advances. For several (or many) key aspects, instead of choosing simple hardware and building a compact driver in Oberon, we now need to step by step begin choosing and using high-performance hardware IP cores (USB, dynamic memory controller, high-speed ethernet and fiber controllers, etc.etc.), and using Oberon to INTERFACE WITH those cores, rather than implementing in software the capabilities which those hardware cores implement. With appropriate care, we need to selectively replace hardware-related items currently performed in (Project) Oberon 2013, with interfaces in Oberon to those items implemented in hardware IP cores. Yes, that will make understanding the full details of those items more difficult, but that's OK! We already have PO2013 for understandability; we should now be trying to multiply system capability and performance by leveraging hardware IP and circuit-level hardware capabilities. Wherever possible we should continue to strive for clarity and simplicity and understandability. However, we ALSO want to strive for performance and capability, and to that end, leverage hardware IP appropriately. We should build clear and understandable and robust interfaces to the hardware IP, And because not every application will require the same hardware or performance, we should be prepared to implement certain interfaces multiple times, using different IP cores. For instance, we may need an interface to a Xilinx-based USB core, an Altera-based USB core, and perhaps a USB core implemented in one or more highly-capable external USB-support chips. Likewise there may be several different memory controllers to support, depending on performance and other requirements. And so forth for other functions. I think the RiskFive project is heading in an excellent direction. High-performance hardware appropriate for multiple sophisticated applications has been designed, in an open manner with much inherent flexibility, considering but not limited by current PO2013 constraints. It will provide an excellent test case and demonstration platform for using Oberon to drive and interface with sophisticated hardware devices and hardware IP, and the nature of the hardware also allows for implementation and comparison of non-Oberon system software as well. -- John Roberts

2 1