November 2020 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Emulators
by Jörg 14 Feb '22

14 Feb '22

Wojtek > How can I proceed, in practical terms, to use your JS emulator for development? Perhaps we should start discussing, WHAT you want to change. At the moment I see three different levels of HW modifications: easy, more difficult, impossible. Basically, see an emulator as virtualization. In virtualization you have a host machine (where the emulator runs on) and a guest machine (this is the FPGA board). I ignore „containers“ at the moment Easy: if you want to extend the RISC-5 instruction set in Verilog (eg add an autoincrement instruction) the modification of the emulator is rather straight forward. I neglect the fact that you have to modify the Oberon-07 compiler to use this new instruction, because this is not important for the emulator. More difficult: if you want to add IO mapped HW (eg Ethernet or Wifi) or memory mapped HW (eg color display) to your FPGA and the host machine has an equivalent of this HW, with a little bit of effort the emulator can be modified to map the IO register commands or new memory layout to the corresponding host HW. Impossible: if you want to add HW to your FPGA and the host machine does not have an equivalent HW (eg a neutrino sensor) then it‘s impossible for the emulator to mimic the new FPGA HW. br Jörg

7 33

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

Ofront+
by Oleg N. Cher 25 Dec '20

25 Dec '20

Dear Oberoners, I'm really surprised that many people here are hearing about Online Oberon for the first time. I've known about it for a long time. In order to inform the public, I want to tell you about my own fork of Josef Templ's project Ofront: https://github.com/jtempl/ofront/ Ofront+ is a direct continuation of the ideas embedded in the Ofront project. But it expands number of supported Oberon dialects: Oberon/Oberon-2 Oberon-07/16 (support is still in-work, but users need to encourage this direction) Component Pascal (almost everything is supported except 2-byte CHAR type, even some GPCP extensions) Oberon-3 (experimental dialect with constant arrays and "proper FOR") We can also use multiple dialects in a single project. Ofront+ also increases the number of available target architectures: BlackBox Component Builder FreeBSD amd64 Linux amd64 Linux armv7 Linux i386 OpenBSD amd64 OpenBSD armv7 OpenBSD i386 macOS X MS Windows 32 bits MS Windows 64 bits Ofront+ was tested and used with C compilers: GCC/MinGW, 32/64 bits Clang SDCC (Small Device C Compiler) Tiny C (tcc) cc65 (for CPU 6502) The latest build of Ofront+ you can get here: https://github.com/Oleg-N-Cher/OfrontPlus I have been working on this for many years and try to keep the project afloat all the time. It's not very documented and it's not covered by a huge set of tests, but I do what I can based on my modest strength. I didn't plan to go that far, I just needed to make a few changes. Then I wanted to make support for Windows. Now we have the result of this work. I still want to do a lot before the release of version 1.0, but this is already quite stable. I won't tell you very much about the differences, but users say that I went too far. ;-) Ofront+ comes as a subsystem for BlackBox and as command line tool (Oberon-like GUI not implemented). So welcome, please use, write reviews and suggestions. Also I provide support for free. I want to thank Josef Templ, who actively supported me and helped me solve many problems. I also want to thank Stewart Greenhill, who made useful improvements and helped fix problems, and developed his own tools for Ofront+. List of differences and improvements: https://github.com/Oleg-N-Cher/OfrontPlus/blob/master/Readme.txt -- Oleg N. Cher

6 11

A technote for automatically running batch job on system startup
by Charles Perkins 23 Dec '20

23 Dec '20

Hello everybody, I wrote a note on how to have Oberon automatically run a startup script. I introduced two small changes to TextFrames.Mod (five lines total) introducing a 'Call Message' and then handling that message with a call to the Call procedure, and three small changes to System.Mod (eight lines total) introducing two variables, opening a viewer with a predetermined text file, and then sending the call message to the viewer at the end of system initialization. https://github.com/io-core/technotes/blob/main/technote013.md I used Michael Schierl's Batch.Mod for the actual batching of commands but Andreas Pirklbauer's system would have worked just as well, or any other batching or script system. The above changes merely call the first command in a text file, the rest of what happens is up to that command. I did this to make building and testing my own system more automatic but I thought I'd share in case anyone found it interesting or useful Best Regards, Chuck

5 5

Has V4 got <default font> like in S3's Oberon.Text ?
by eas lab 02 Dec '20

02 Dec '20

If you bought a laptop during recent decade/s and into the forseeable future, you'd be locked into the M$hit-monopolist. A valuable capability of our Oberon-family is the <ability to see/manipulate multiple files simultaneously on the same screen>. Oldies suffer from short-term memory disabiity :-( This valuable capabilit y, which puts us in the same family-line as plan9, was inherited from <PARC>, but is never acknowledged - AFAICS? >From years ago, I installed V4 to have this capability under M$pook, but can't find HOW2/IF install a big-bold default font like S3 could. --Please advise.

13 28

[EXT] Oberon V4 Windows startup oberon.exe
by Andreas Pirklbauer 30 Nov '20

30 Nov '20

> Andreas: > > I think it is wise to stay with one compiler. I remember that the number of LOOP > statements in the original Oberon System was small. The RETURN statements > are a bigger issue for me because I use them quite often to exit the procedures. > I have some bright ideas to implement, so work on B2 is unavoidable anyway. > I am more worried about the rest of the V4 than about my own stuff which > will evolve anyway. > > Thank you, > Wojtek If you do it in a single compiler, make sure to keep the features nicely separated, e.g. via an option or something. Personally, I dislike LOOP, EXIT and RETURN in the middle of a procedure, as they run counter to the idea of structured programming. This is one of the reasons why I decided to not go back to the original Oberon-2 spec, fully knowing that lots of legacy code will not compile anymore, i.e. one needs to refactor. -ap

1 0

[EXT] Oberon V4 Windows startup oberon.exe
by Andreas Pirklbauer 30 Nov '20

30 Nov '20

> Andreas: > would it be possible to bring your compiler closer to the previous Oberon-2 implemented under V4 in order to make porting a bit easier? It’s definitely possible, but the choice made was to implement (now revised) Oberon-2 as a superset of Oberon-07, in order to benefit from the refinements made in the language over the years, e.g., the elimination of the LOOP, EXIT and RETURN (in its original form) statements plus several other smaller changes. The upside is (in my view at least) a cleaner version of Oberon-2. The downside is, of course, that if you want to port V4 using *that* Oberon-2 compiler, you’d need to refactor and touch the source code of *many, many* source files, replacing al LOOP statements with WHILE statements, etc. A tedious task! But a one-time effort. PS: If someone (not me!) volunteers to build an “original” Oberon-2 compiler for FPGA RISC5, I would recommend building an entirely separate compiler, i.e. *not* mix and match features.

2 1

[EXT] Oberon V4 Windows startup oberon.exe
by Andreas Pirklbauer 29 Nov '20

29 Nov '20

> "Oberon-2" parser frontend with a "RISC5" code generator backend. This does not exist so far. There is actually an Oberon-2 compiler for NW’s FPGA RISC5, but it cannot be used to compile LinzOberon on FPGA as is, because the FPGA Oberon-2 compiler implements a superset of the Oberon-07 language (i.e. it uses CASE T OF instead of WITH T DO for the type case statement, it has no LOOP statement, etc) rather than the original language Oberon, as defined in 1988.

2 2

Nomeclature.
by peter＠easthope.ca 28 Nov '20

28 Nov '20

From: =?UTF-8?B?SsO2cmc=?= <joerg.straube(a)iaeth.ch> Date: Sat, 28 Nov 2020 11:45:24 +0100 > To have a system like LinzOberon on FPGA, you would need to mimic > the HW it's running on. Joerg, I guess you prefer the name LinzOberon or Linz Oberon over V4. Analogous to preference for ETH Oberon over S3. Correct? Is the " " significant? "LinzOberon" vs. "Linz Oberon". > There are systems where all objects have a common type all objects > are inherited from (S3, AO) ... I guess "S3" and "V4" are tolerable where the context leaves no doubt that the canonical or official names are ETH Oberon and Linz Oberon. Correct? In the wikibook there is no difficulty changing "Oberon/V4" to "Oberon/Linz Oberon", if that is advisable. Thx, ... L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

Re: [Oberon] [EXT] Oberon V4 Windows startup oberon.exe
by Jörg 28 Nov '20

28 Nov '20

Wojtek Without really doing it, your simple question can't be answered easily. It all depends! Generally, the Oberon system covers four parts A) The programming API (aka procedures) your modules use B) The Oberon language your modules are written in (the language constructs you're using) C) The CPU the Oberon system is running on D) The HW the Oberon system is running on A) is (not completely but) fairly stable across all NW Oberon systems Unless your application modules uses very HW specific things, it can be ported quite easily from system to system. That said there are however a few catchups: Texts and Objects. There are systems where Texts has extensions and systems without. So the API to Texts.Mod is not completely stable. There are systems where all objects have a common type all objects are inherited from (S3, AO) and there systems where this is not the case. B) Here you have basically two different approaches: 1) Either you have a compiler (see point C) below) for the Oberon language your modules are written in. Or 2) you port your code from one Oberon language to the other. Oberon went through different steps of evolutions: starting with Oberon-1 to the enhanced Oberon-2, taking a different approach with ActiveOberon and kinda back to the roots with Oberon-07. (neglecting all the dialects of the mentioned languages for a moment) Depending on the language constructs you were using, the porting task is rather easy, fairly complex or almost impossible. C) There is a handful of CPUs (or better ISAs) the compiler can have as target: x86, x64, Sparc, ARM, RISC-V, RISC5... As seen in B) there is also a handful of Oberon languages. For the compiler this multiplies out: L languages on M machines = L*M different compilers. It's often that you have L frontends (language parsers) with M backends (code generator). For LinzOberon on FPGA, you would need the combination: "Oberon-2" parser frontend with a "RISC5" code generator backend. This does not exist so far. D) the HW is quite different from machine to machine. Here some examples: memory size, file system, display size, color depth, IO addresses, networking... So the HW-dependent SW layer (aka HW drivers) like Input, Display, Kernel, FileDir etc. have to be adapted accordingly. To have a system like LinzOberon on FPGA, you would need to mimic the HW it's running on. It depends on the language constructs you were using in your modules. From what I see in the screenshot you attached, I'm just guessing: I could imagine that porting your code over to Oberon-07 is faster than waiting for an Oberon-2 compiler for RISC5 Assuming you modified the Verilog to offer color graphics and enough RAM ( br Jörg Am 28.11.20, 03:51 schrieb "Oberon im Auftrag von Skulski, Wojciech" <oberon-bounces(a)lists.inf.ethz.ch im Auftrag von skulski(a)pas.rochester.edu>: Joerg: thank you. I made the change. I often run my computer w/o rebooting. I started looking into V4 in some more detail after I decided to dust off my B2 Data Analysis Framework developed in 1996-1998. It was sitting somewhat forgotten in my archives. The attached display may not be meaningful to you. A nuclear physicist will recognize the dE versus E in the upper plot, neutron multiplicity versus charged particles in the middle one, and 1D histogram in the lower one. I wrote not only this framework, but also extensive documentation. I will post it on RiskFive, time permitting. So now I am thinking how I can port this to FPGA Oberon. Ideally the entire V4 would be ported as well because it is just wonderfully useful. So I looked into V4 Kernel.Mod and I can appreciate how different it is from the V5 aka FPGA Oberon. I wonder where is the line between lower system modules like Kernel or Display, and upper modules like Edit, Elements, or Dialogs. Porting the lower level is probably hopeless. Too many dependencies on the OS. But the upper level should be portable. Unfortunately the language has been changed. I wonder how many code changes will be necessary to port V4 to FPGA Oberon System. Of course I know that a new board will be needed. RiskZero with its 4 MB is probably sufficient. Your Pipistrello will be more than sufficient. Thank you, Wojtek ________________________________________ From: Oberon [oberon-bounces(a)lists.inf.ethz.ch] on behalf of Jörg [joerg.straube(a)iaeth.ch] Sent: Friday, November 27, 2020 8:16 AM To: 'ETH Oberon and related systems' Subject: [EXT] Re: [Oberon] Oberon V4 Windows startup oberon.exe Wojtek In case you're building LinzOberon new, you might correct the following small error: In "Files.GetTempName()" change "n := tempno;" to "n := tempno MOD 80000000H;" If your Windows system runs for more than 24 days without a boot, tempno might be negative. The WHILE in GetTempName only works if n>=0. 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

1 0