February 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

oberonstation vs. a $9 computer
by skulski＠pas.rochester.edu 14 Jul '16

14 Jul '16

Lars: It is sort of funny that one can use the low price as an argument. How much do you value your time? Let's say it is $5 per hour, way below minimum wage. How much time will you spend on getting anything done with any piece of hardware, be it Arduino, RPi, Beagle Bone, or Oberon Station? Are you going to achieve anything meaningful in less than 10 hours? If so then I will consider hiring you for $50 per hour. The low price does indeed matter if you will use the hardware in a finished product. They are talking of a disposable computer. If you are going to basically throw it away after a single use (provided that you environmental soul lets you do it), then indeed $9 matters. But if you are going to do any development or experimentation with the HW, then you will likely spend hundreds of hours doing so. Then it does not matter if you invest $9, $90, or even $900 into your hardware. Almost any such amount is dwarfed by the cost of your time. Oberon Station is a development platform. The valid question is "development of what?". The initial dollar investment in the development hardware is not that important in this case. W. > The oberon station is tempting, but with Raspberry Pi at $35 > or the C.H.I.P computer for $9.00... that has USB, > and WIFI that works like any wifi, the oberon station > is really priced way out of the market. If the > oberonstation was around $50 more people would buy. > How can you possibly compete with the C.H.I.P. > for $9.00.

10 23

Standalone BlackBox programs was: GUI programming in Oberon.
by Treutwein Bernhard 11 Apr '16

11 Apr '16

Lars, >>> There is no way to ship a standalone exe GUI program, Wrong. Please check before you set such a statement in the wild. >How did you ship an exe standalone? modify the blackbox source code, or >use a different compiler? There are several way, the basic one is documented in the "Platform-Specific Issues". BlackBox.exe itself is created with BlackBox. See "Linking BlackBox Applications" in the Document mentioned above. Moreover you can pack a complete filesystem in the exe, see <installed directory>/Dev/Spec/PackedFiles.odc -- Bernhard >-----Original Message----- >From: Lars [mailto:noreply@z505.com] >Sent: Monday, February 29, 2016 1:36 AM >To: ETH Oberon and related systems >Subject: Re: [Oberon] GUI programming in Oberon. > >On Sat, February 27, 2016 8:54 pm, Douglas G. Danforth wrote: >> On 2/27/2016 7:07 PM, Lars wrote: >> >>> There is no way to ship a standalone exe GUI program, >>> >> Not true. I have written a number of .exe programs developed in >> BlackBox for >> paying customers. > >Well, you can even sell applications that run inside the blackbox >environment. > >How did you ship an exe standalone? modify the blackbox source code, or >use a different compiler?

11 14

Oberon with strings, Eberon
by Lars 11 Apr '16

11 Apr '16

Found an oberon programmer who "gets it".. i.e. spinach https://github.com/vladfolts/oberonjs/wiki/Eberon-Strings Have to research this. I'm posting it to the list to make it more known that there are people who know of the string problem and aren't denying it. With all these forks of oberon, it's the same problem as standard pascal. You have about 200 different versions of pascal floating around, because standard pascal was castrated and circumscribed in its standard form. So people extend it which fragments the community into hundreds of forks.

7 17

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

Oberon Runtime Environment running Oberon byte-code
by Srinivas Nayak 06 Mar '16

06 Mar '16

Dear All, To my knowledge, Oberon programs needs a runtime environment with 1. command activation 2. garbage collection 3. dynamic loading of modules 4. certain run-time data structures Although not part of the language, this environment is implied by the language definition. And this empowers Oberon. If this is the case, like Java, would a Oberon Runtime Environment running Oberon byte-code have been better? Is there a limitation in this scheme? Looks like, Michael Spivey with Oxford Oberon-2 compiler proceeded with similar scheme... I would like to know if there is any reason, we didn't make it like java... I hope that would have solved taking Oberon to different platform easy. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

6 5

Re: [Oberon] Accessing Oberon RISC5 files on other computers
by skulski＠pas.rochester.edu 03 Mar '16

03 Mar '16

John R. Strohm [strohm(a)airmail.net]wrote: >At that point, you are talking about a FATnn (FAT12, FAT16, FAT32, > if memory serves me) filesystem on the SD card, and adding > a FATnn filesystem to your Oberon system, plus code to recognize > that a random SD card plugged into an > Oberon system has a FATnn filesystem already on it. Obviously. I am talking of whatever needs to be done to transfer the data in a reasonable way. If it is FAT, let it be FAT. > Which is kind of a mess, not to mention proprietary. Every real product is a mess. How else? Are we insisting on worshiping a gold plated ivory tower? Beautiful, clean, and useless? Wojtek

3 2

Fast version of Oberon RISC5 for Pepino
by Magnus Karlsson 01 Mar '16

01 Mar '16

One outcome of the discussion about the Oberon RISC5 verilog code is that I did a deeper study about the clock limits for the project and found that the RISC5 CPU in itself can be clocked at up to about 66 MHz but the external SRAM path is too slow for that speed (read is the problem). The asynchronous nature of the SRAM interface makes it hard to constrain the ISE compiler to work hard on this path. I did trace the SRAM read data path and found that it takes about 10 ns from the SRAM data input pins to the Z register bit (this is the longest path). The address output path is about 5 nS and with a 10 nS SRAM access time the fastest system clock cycle should be around 25 nS. To test this out I created a version of the code that runs the CPU at 37.5 MHz (26.666 nS) instead of 25 MHz, i.e. the CPU is running 1/2 the video clock rate instead of 1/3, and it seems to run fine of both the LX9 and the LX25 version of Pepino. All timing constants (UART Rx, UART Tx, SPI and millisecond timer) have been changed to reflect the 50% faster clock rate. If anyone want to try it, the project (including bit files) is available here: https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino… Cheers, Magnus

3 5