January 2016 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Concurrency support in Oberon
by John R. Strohm 25 Nov '16

25 Nov '16

No, Oberon has no concurrency support in the language. The Oberon system provides a simple event loop, that allows programmers to do simple round-robin run-til-done scheduling. --- sinu.nayak2001(a)gmail.com wrote: From: Srinivas Nayak <sinu.nayak2001(a)gmail.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: [Oberon] Concurrency support in Oberon Date: Thu, 21 Jan 2016 20:27:05 +0530 Dear All, We had Pascal, We came to its successor Modula-2. Then we came to its successor Oberon. But do we still have the concurrency programming support in Oberon, which was present in Modula-2? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/ -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

16 24

Re: [Oberon] Availability of OberonStation
by Chris Burrows 14 Nov '16

14 Nov '16

> > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Ken Boak > Sent: Monday, 18 January 2016 7:29 PM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Availability of OberonStation > > Have any of the list had experience of the Oberon system on the > Xilinx Artix-7 - specifically on the $99 Arty board - is this a > preferred platform? > It is likely that I have had the most experience on the Xilinx Artix-7 seeing as I ported our 'embedded' subset of ProjectOberon to the Arty board ;-) I agree with Walter. Oberon-07 is an ideal language for developing embedded applications. I'm not sure what you mean by 'preferred platform'. The Arty (Artix-7) and the Pippistrello (Spartan-6 LX45) development boards are the only two I have found so far that have sufficient BRAM to run embedded ProjectOberon without external SRAM. Saanlima's Pippistrello is about $50 more than the Arty. However, the Pippistrello does have a built-in SD Card socket and can also be used as an ProjectOberon Workstation development system with Saanlima's optional Oberon SRAM 'Wing'. There are many simpler FPGA boards available but all the ones I have found use less-capable FPGA devices with insufficient BRAM. The Arty and the Pippistrello have more features than are needed for embedded Oberon applications like those on the ARM Cortex-M3/M4 boards that we support. However, I guess that doesn't matter for those who are designing their own boards and just want an off-the-shelf reference system to use for prototyping / proof of concept. If on the other hand you want to run the complete Project Oberon 'workstation' system with VGA / HDMI, keyboard and mouse. You will need a board with external SRAM like the OberonStation. An Arty would not be suitable for this purpose. > Finally, and perhaps best addressed to Chris Burrows - I see that > you have produced packages for the ARM M3 and M4 Cortex - mainly NXP. > Do you have any aspirations to port to Cortex M7 - such as the $50 > STM32F7 Discovery Platform - which has a great selection of useful > hardware on-board? > There used to be an clear distinction between the simple 8-bit microcontroller at one end of the spectrum and the 64-bit PC at the other. In recent years the two have started to converge. The embedded systems are becoming more powerful; the PCs are becoming smaller and less power-hungry - the distinction is blurring. The STM32F7 Discovery Platform seems to me to be more a miniature PC than a high-power embedded system. While we remain focused on supporting embedded systems we are unlikely to be targeting it, Regards, Chris Chris Burrows CFB Software http://www.astrobe.com/RISC5

34 147

Oberon language family and the master.
by Srinivas Nayak 05 Sep '16

05 Sep '16

Dear All, I am referring to http://www.oberon.ethz.ch/archives/languagearchive/genealogy. Here we see that Oberon language from its birth has gone through several revisions. Many times either NW or others have added new features to it if they feel a need of it. Or removed existing features, if they found it unnecessary. After all these iterations, Oberon might have got time tested. So today, can we say, whatever is present in Oberon-7 is time tested; and one doesn't need to add or remove anything from it; and this is the state-of-the-art; and is simple but not simpler? If so, one wouldn't worry about Oberon V, Oberon X, Active Oberon, Action Oberon, Object Oberon, Concurrent Oberon etc. etc. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

4 4

RISC5 Oberon on a $99 FPGA Development Board
by Chris Burrows 31 Mar '16

31 Mar '16

We have now successfully ported the RISC5 processor to Digilent's latest 'Arty' development board which uses the Xilinx ArtixR-7 35T FPGA device and retails at $US 99: http://www.xilinx.com/products/boards-and-kits/arty.html We are planning to support our 'Embedded' version of Project Oberon (i.e. not the full 'Workstation' version) running in the BRAM on this board. For more information on the Embedded and Workstation Project Oberon systems that can be used with the Astrobe IDE and to register your details to be notified when the Arty-targeted version is available go to: http://www.astrobe.com/RISC5 Regards, Chris Burrows CFB Software http://www.astrobe.com

7 8

Astrobe for FPGA
by greim 13 Feb '16

13 Feb '16

Hallo Chris, > > Yes - editing, compiling and uploading are all done on the PC using the > Astrobe IDE. The Oberon source code files on the PC are just text files so > you can use any of your other Windows software development tools (editors, > difference listers, version control systems, grep searches) to maintain > them. The resulting modules (*.rsc files) are dynamically linked on the FPGA > exactly as they are in the full Project Oberon system. > > The core OS modules that I use - Kernel, FileDir, Files and Modules (the > dynamic loader), are identical to the Project Oberon distribution except for > one difference: I have implemented a Files.SetDate function that I call from > the Upload function so that files uploaded from the PC have the same date / > timestamp on the Oberon system. > > As for a 'business model' Astrobe for FPGA RISC5 is free - you'll just have > to register your name and email address to use it: > > http://www.astrobe.com/forum/viewtopic.php?f=13&t=476 > > The downside is that you will get half-a-dozen or so Astrobe-related emails > from me each year ;-) > thats ok, i guess i already got it, because afaik I have a license for ARM... > Support is limited to this mailing list and the Astrobe forum. Anything else > that would create work for me which I am not already doing for myself I > would have to charge for e.g. helping you to get it working on a board that > you have built or purchased for your own or commercial use. An exception > would be for individuals like Magnus (Saanlima) or Enso who were developing > a board specifically aimed at supporting Oberon. I am happy to try and help > them if possible - the only cost to them would be to send me a board to work > with. If Xilinx or Altera was the customer that might be a different story > :) > ok, thats a very fair business model > No Linux version of Astrobe for RISC5 is planned - it requires Windows 7, 8 > or 10. > > If you wanted a Linux version you would be able to use the target system as > long as you had a Linux tool to write the supplied core OS disk image to an > SD Card. You would also need: > > * A Linux text editor to create your Oberon programs > * To port the RISC5 Oberon compiler to Linux. > Gardens Point Component Pascal (GPCP) for JVM might be a good starting > point. It only took a couple of days to port the compiler using GPCP for > .NET > * A Linux terminal emulator that can run at 115200 baud to upload the object > files (*.rsc) to the target. ok, maybe i will make a try with WINE, but i have also Windows in a container on my Linux desktop, i must confess.... > > Sorry - I missed your last question in my previous reply. Yes you can use > the full featured FPGAOberon system as your developing/master system. You > just need a way of transferring the resulting .rsc files from the full > system to your target system. I'll supply a disk image for the full system > as well as the core OS to make sure that the module versions are compatible. > that sounds very elegant... One last question regarding this topic: The timing of the full FPGAOberon is strongly influenced by the CRT refresh rate. Is there any speed/clock-frequency increase with your slim system realized/possible? Best Regards Markus

2 2

Re: [Oberon] Compiling Original Oberon in (Unix)Aos?
by jwr＠robrts.net 05 Feb '16

05 Feb '16

Hmmm.. There is a key clue (but I still don't fully understand) in Eric Scharff's original message at http://lists.inf.ethz.ch/pipermail/oberon/2016/008792.html. He mentions both Oberon and Oberon-2, and indicates that there is an "Oberon subsystem" within AOS. Perhaps there is one "Oberon subsystem" when there should be two? One for (original) Oberon, and one for Oberon-2? This would suggest at least THREE contexts (or "subsystems"?) in which code can be compiled: one for AOS, one for Oberon, and one for Oberon-2. There may need to be a different compiler used in each context, and code compiled for or within one context should not be used by code in another context? Perhaps the problem Eric has encountered is related to the contexts for Oberon and Oberon-2 not being sufficiently well defined and separated? Again, I am concerned I misunderstand something very important. Please clarify. -- John Roberts

3 4

Acronyms and Versions
by jwr＠robrts.net 01 Feb '16

01 Feb '16

In December I purchased an OberonStation, and am currently trying to understand which implementations of Oberon (in addition to that of Project Oberon 2013) are also valuable to obtain and study. I reviewed the last four years of messages on this list, and am still somewhat confused. Perhaps it is useful to contribute summaries of acronyms and versions which others on this list can help correct and refine. In http://lists.inf.ethz.ch/pipermail/oberon/2016/008750.html Peter Easthope states “A glossary containing some of these commonly bandied names and acronyms would be helpful.” In http://lists.inf.ethz.ch/pipermail/oberon/2015/008219.html Dieter Gloetzel says: “Is there anywhere a list of abbreviations? e.g. "LNO" or "OLR". I have difficulties following the discussions.” At http://lists.inf.ethz.ch/pipermail/oberon/2016/008763.html Srinivas Nayak asks “Which version of Oberon I should look at? Oberon-7 or Active Oberon or Concurrent Oberon or ?” and Bob Walkden answers “Why not look at them all?”. I think it's hard to look at them “all” because there are so many variations, it is difficult to enumerate them. Also it is somewhat unclear which involve versions of the language, which involve versions of the system implementation, which involve different experimental or useful versions of tools and applications, and which are versions identifying distributions for different underlying hardware and OS platforms. It is also difficult to identify which particular ones contain the most useful or most important components to study. Perhaps with help from the experts on this list, we can more fully enumerate the versions, and identify what is unique and useful or special about each one. Here is a summary of acronyms and version names I have gleaned from various messages and sources. Please provide feedback and corrections as appropriate. ALO ARM Linux Oberon (Oberon in LNO family, for ARM CPU eg Raspberry Pi) ETHO ETH Oberon (ETH is Eidgenössische Technische Hochschule Zürich) LEO Linux ETH Oberon [ETHO 2.4.3 for Linux x86] LNO Linux Native Oberon NO Native Oberon OCP Oberon Community Platform OLR Oberon Linux Revival Is ETH-Linux-Oberon the same as LEO or LNO? (Probably it is LEO.) Is Linux-ETH-Oberon the same as LEO? Same as ETH-Linux-Oberon? See https://lists.inf.ethz.ch/pipermail/oberon/2015/007996.html and https://lists.inf.ethz.ch/pipermail/oberon/2008/005410.html BB BlackBox Component Builder, Component Pascal IDE from Oberon Microsystems, http://www.oberon.ch/blackbox.html CP Component Pascal [A dialect in the Oberon family most similar to Oberon-2] AOS Active Object System (2003) UnixAOS Unix-based AOS WinAOS Windows-based AOS Bluebottle New system based on AOS kernel (2005) A2 New system after Bluebottle (2008) See http://www.oberon.ethz.ch/ for AOS/Bluebottle/A2 history Crazy-Fresh Bluebottle [see http://www.ethoberon.ethz.ch/] Crazy-Fresh A2 [see http://sourceforge.net/projects/a2oberon/files/] ----- The following appear to be versions of the language definition itself. In another message another day I plan to identify documentation for each. Original Oberon (1987/88/90) Revised Oberon (1992) [later called Oberon-07] Oberon-2 is a compatible superset of Revised Oberon (1992) Oberon-07 is a new language based on Oberon and Oberon-SA See http://oberon07.com/ and http://oberon07.com/FAQ.xhtml See https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.pdf See https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf Project Oberon (1992) Ceres-based NS32032 implementation of Revised Oberon see http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf Project Oberon (2013) FPGA-based RISC5 implementation of Oberon-07 see http://www.projectoberon.com/ and https://www.inf.ethz.ch/personal/wirth/ Oakwood Guidelines for Oberon-2 Compiler Developers ----- Other names found for various Oberon implementations and versions include: Oberon S3 = Oberon System 3 (Became ETH Oberon) Oberon V4 (Associated with both ETH and University of Linz) See http://sourceforge.net/projects/oberon/ and http://www.ssw.uni-linz.ac.at/Research/Projects/Oberon.html See http://users.cms.caltech.edu/~cs140/140a/Oberon/system_faq.html for Oberon = V1 ( V2 V4 | System3 ) Oberon V1 [Original Oberon??] Oberon V2 [??] Oberon V4 [Started at ETH, more development at University of Linz] Oberon System3 [Became ETH Oberon] Native Oberon [Based on ETH Oberon] (see http://www.oberon.ethz.ch/downloads/index for current versions) (see http://www.oberon.ethz.ch/archives/systemsarchive/native_new) PC Native Oberon [for Intel-compatible PCs] PC Native Oberon for Dummies [for Windows installation] Linux-based Native Oberon [LNO] SharkOberon [for DEC Shark Network Computers, ARM-based] Native Oberon Alpha [http://www.oberon.ethz.ch/faq/faqnativealfabeta] Native Oberon Beta [see same link as Alpha] Versions at http://www.oberon.ethz.ch/archives/languagearchive/genealogy Oberon Oberon-V Oberon X Active Oberon Oberon-SA Active Oberon for .NET Object Oberon Oberon-2 Concurrent Oberon Action Oberon Oberon-D Component Pascal Versions at http://www.ethoberon.ethz.ch/genealsys.html not already above SPARC-Oberon MacOberon DEC-Oberon RISC Oberon MS-DOS Oberon Chameleon Oberon HP-Oberon Oberon for Windows Spirit of Oberon Hybrid Oberon Oberon for Linux Oberon Linux PPC more versions named according to supporting OS? ----- I have also seen terms Oberon-0 and Oberon0. Definitions may be: Oberon-0 a particular Oberon language/compiler see https://en.wikipedia.org/wiki/PL/0 Oberon0 implementation of an Oberon-0 compiler (?) or minimal Oberon system (?) Oberon0.dsk disk image for bootable Oberon0 installer (see http://sourceforge.net/projects/nativeoberon/files/nativeoberon/Oberon0%20b…) Another acronym observed is OP2, which is a Portable Oberon compiler by R Crelier -- John Roberts

2 1

Re: [Oberon] Compiling Original Oberon in (Unix)Aos?
by jwr＠robrts.net 30 Jan '16

30 Jan '16

At http://lists.inf.ethz.ch/pipermail/oberon/2016/008795.html Günter Feldmann wrote in answer to Eric Scharff: in the long period form 1989 to today the Oberon language as well as the object file format got some improvements. Some of them are incompatible. Therefore the old compiler and builder in the Oberon subsystem don't work any more, but they have to stay as parts of the old compiler get imported by modules belonging to other parts of the system. You can compile your module with the compiler in Aos and then start it in the Oberon subsystem. Please help me understand, I think I misunderstand something critical. It sounds to me like this (UnixAOS) distribution is partially "broken", in that it is currently in a state different than it would be if everything was recompiled from source. Some objects currently exist with incompatible object-code formats?! Also it sounds like certain source files are written in different (incompatible?) "dialects" of the Oberon language. This suggests there is a significant possibility that right now the release cannot be completely recompiled successfully. Recognizing that there is a chicken-and-egg problem regarding bootstrapping the compiler(s) [whose solution is well known and documented], are the proper procedures documented and available for cleanly recompiling everything in UnixAOS from scratch? Has anyone recently verified the procedures work properly? Is that useful/Does anyone care? Theoretically there should be a file within the distribution which describes the exact procedure (with the proper commands listed) to recompile everything cleanly and properly. Perhaps not everything should be compiled with the same compiler: there may be a set of files compiled by the AOS compiler, another set by Oberon compiler #1, and yet another set by Oberon compiler #2, but it should somewhere be very clear exactly what to do. -- John Roberts

1 0

Correction; ORD usage & etc.
by peter＠easthope.ca 30 Jan '16

30 Jan '16

From: peter at easthope.ca (Peter Easthope), Fri, 16 Oct 2015 18:39:58 -0500 > menuH := Fonts.Default.height + 2; > barW := menuH; > INC(menuH, ORD(Modern) * 6); The argument of ORD is CHAR; not BOOLEAN. This is more likely to succeed. (* Kronecker delta *) PROCEDURE Kd(b: BOOLEAN): INTEGER; BEGIN IF b THEN RETURN 1 ELSE RETURN 0 END END Kd; ... INC(menuH, Kd(Modern) * 6); The genuine Kronecker delta tests equality of two arguments. So this is a distortion; but understandable. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

2 1

Re: [Oberon] Input.Timer in Native Oberon
by Chris Burrows 30 Jan '16

30 Jan '16

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > peter(a)easthope.ca > Sent: Sunday, 31 January 2016 2:13 AM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Re (2): Input.Timer in Native Oberon > > From: Chris Burrows <chris(a)cfbsoftware.com>, Fri, 29 Jan 2016 > 08:04:10 +1030 > > ... values 100 and 12 have a certain significance in this context? > > Sorry but 100 and 12 are magic numbers. 2% docked from grade for > each. > OK :( > > > PixelCount = 1024 * 768; (* Better than PixelCount = 786432; *) > > You might be astonished at the number of students in a first year > class who don't recognize "1024 * 768". No - it doesn't surprise me. However it would surprise me if those same students knew what a 'pixel' is. They might have some idea of what a 'megapixel' is perhaps because they have a few of those in their phones. ;-) > > Absolutely! I gave names to the magic numbers. Much better! Also: 1. Replace 'KP' with 'KeyPad' (or at least 'Key') and there is no need for the comment. 2. Use camel-caps consistently. E.g. what is a 'pollinter-val'? Should be KeyPollInterval 2% docked from grade for each. > > Incidentally, Timer is not an enlightening name for the procedure. > Too general. It does more than time. KPpointer? KPcontroller? > Many names could say more than "Timer". > Agreed. CursorKeyTimer, KeyPadTimer or at least KeyTimer for those who don't like long names. Regards, Chris

1 0