June 2021 - 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

Re: [Oberon] _Compiler_Construction_ by Niklaus Wirth
by peter＠easthope.ca 17 Nov '21

17 Nov '21

P.s. for interest. From: peter(a)easthope.ca Date: Thu, 07 Jan 2021 08:37:22 -0800 > Currently the cheapest copy of _Compiler_Construction_ is 43.09 US$, > delivery in the USA included. Appears the copy posted at 43.09 US$ was sold that day. Subsequently the vendor listed another copy at 105.61 $US. The book market can be as volatile as the stock market. Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

8 21

Oberon On RISC Controller
by daniel.schmid＠bluemail.ch 26 Jun '21

26 Jun '21

Dear Oberon-Listeners Does anybody have experience with Oberon on a (RISC) Microcontroller? With the Arduino-IDE it is quiet easy to program (C) an Arduino Controller. Now i found such an industrial grade one (Controllino) which works nice. As i'm using Oberon (A2) within Linux (Debian), i'm wondering if anybody knows to compile an Oberon-hexfile for an Arduino compatible (ATmega) RISC Microcontroller? Would be great for training and industrial application. Or otherwise, is there a proven public transpiler from Oberon to C around? Many thanks for any hints. Kind regrads, Daniel.

2 1

Portings Texts.Mod to Oberon-7, my Artemis project
by Andreas Pirklbauer 20 Jun '21

20 Jun '21

> The Oberon-07 language report does not define the implementation of CHAR. > It can be 8 bits, 16 bits or even longer. The language does only define ORD, but > does not define what ORD returns. It might be ASCII, it might be EBCDIC or Unicode. Could one therefore change the implementation of the data type CHAR such that it can be Unicode, while simultaneously keeping the implementation backward compatible, i.e ideally such that no c(!) ode in the system needs to be changed? > Principally, all program code using someting like ORD(ch)-48 is not portable. > Better is ORD(ch) - ORD(“0“). All program code assuming CHAR to be one byte > is not portable. Use BYTE instead. Of course, in places where non-portable code exists in the system, one would then need to adapt it.

1 0

Portings Texts.Mod to Oberon-7, my Artemis project
by Robert Doiel 20 Jun '21

20 Jun '21

This list discussion around Oberon Texts has been inspiring. It is been so inspiring I've create a GitHub repository named Artemis: > Artemis is an Oberon-7 module collection. My hope is > to encourage continued use and development of the Oberon-7 > language and encourage convergence towards compatibility > in implementations of Oberon-7 compilers. This ties back to the Texts discussion in one significant way. I am planning to port both S3 (Native Oberon) Texts.Mod and V4 (Linz) Texts (Texts.Mod, Elem.Mod, etc) to Oberon-7. That code will wind up in Artemis and be used to implement an "ocat" (like Joseph Templ's ocat from ofront) that will work for each of the type of Texts. I've looked at each implementation and I think unifying them is beyond my skill but porting each one would be extremely useful, especially from a preservation point of view. I am not promising fast (or successful) development. I am one of those dreaded hobbyist when it comes to Oberon. I think the collection will be useful as it evolves. It is likely to hold my interest for quite some time. I think it will be especially for useful for fellow novices exploring Oberon-7 on POSIX. https://github.com/rsdoiel/Artemis Feed back welcome, criticism is helpful, pull request exciting. You can reach me on this email list and via GitHub issue (https://github.com/rsdoiel/Artemis/issues) All the best, Robert Doiel

7 11

Re (2): Re (2): Re (2): UEFI
by peter＠easthope.ca 16 Jun '21

16 Jun '21

From: Liam Proven <lproven(a)gmail.com> Date: Tue, 15 Jun 2021 18:57:17 +0200 > IME ... used to be purely for remote management of server hardware. IME is enough to exclude a network connected modern PC from a safety critical application. An unpredictable glitch or failure of a machine which could cause death or serious injury is intolerable. Similarly for an application with significant resources at risk. In banking for example. Similarly where scientific or industrial espionage is possible. The only way to prevent illicit access is make sure there is no back door. Hence a FPGA based embedded system or workstation. A workstation such as being developed by Wojciech. Regards, ... P.L. -- tel: +1 604 670 0140

3 2

Just stumbled across this in connection with my blogpost from last night
by Liam Proven 16 Jun '21

16 Jun '21

http://www.edm2.com/index.php/Oberon -- Liam Proven – Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk – gMail/gTalk/gHangouts: lproven(a)gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

2 2

Re (2): Re (2): UEFI
by peter＠easthope.ca 15 Jun '21

15 Jun '21

From: Liam Proven <lproven(a)gmail.com> Date: Tue, 15 Jun 2021 17:21:12 +0200 > > https://en.wikipedia.org/wiki/Intel_Management_Engine > > Aha! Right. That is an entirely unrelated issue. IME is separate from UEFI. Correct? IME provides another way that an external party might access a machine for a purpose unwanted by the machine owner. UEFI imposes another layer of complexity not intrisic to the user objective but requiring attention for the machine to serve a purpose. In the Oberon philosophy, neither of those is desirable. Regards, ... P.L. -- tel: +1 604 670 0140

4 3

Re (2): UEFI
by peter＠easthope.ca 15 Jun '21

15 Jun '21

From: Liam Proven <lproven(a)gmail.com> Date: Tue, 15 Jun 2021 16:23:28 +0200 > UEFI is not proprietary and it is documented: > https://uefi.org/specifications > > UEFI is derived from EFI. EFI is Intel's firmware for Itanium > computers. EFI is proprietary. UEFI is not. Thanks. > What backdoor problem is this? https://en.wikipedia.org/wiki/Intel_Management_Engine > Is it [Oberon on the Skulski machines] not already? V5 might work now. Fairly sure that none of V4, ETH Oberon and A2 work yet. Regards, ... P.L. -- tel: +1 604 670 0140

2 1