- Oberon - mailman3.inf.ethz.ch

Re: [Oberon] SYSTEM.COPY (was: Compiler behaviour for a32 := a8)
by Chris Burrows 01 Feb '21

01 Feb '21

> -----Original Message----- > From: Hans Klaver [mailto:hklaver@dds.nl] > Sent: Tuesday, 2 February 2021 12:10 AM > To: Chris Burrows; ETH Oberon and related systems > Subject: Re: [Oberon] Compiler behaviour for a32 := a8 > > Chris wrote: > > > Note that SYSTEM.COPY is now provided to efficiently copy n words > from > > an array of one type to another of the same or different type. > > I would consider it an abuse of SYSTEM.COPY to use it for assignment > of one variable of an anonymous ARRAY len1 OF CHAR type to a variable > of another anonymous ARRAY len2 OF CHAR, and using it would be > unwieldy and unhelpful: > - unwieldy because it would involve several SYSTEM-dependend type > casts, > - unhelpful because it would not warn for string truncation. > I'm sorry - I should not have mentioned it as it only adds to the confusion. It might conceivably be useful if a character array being copied was being used to contain data that did not represent a null-terminated string. Whatever, SYSTEM.COPY should only ever be used with *great* care and only in cases of extreme need. No type casts are required as the definition is COPY(src, dst, n) where ALL of the parameters are INTEGER. Hence, arc and dst would need to be the addresses of the data (e.g. obtained using SYSTEM.ADR) and n would need to be specified as no greater than the number of words in the smaller of the two items to avoid any nasty problems. The only example of its use that I can find in Project Oberon is in SCC.SendPacket: SYSTEM.COPY(SYSTEM.ADR(head), SYSTEM.ADR(payload), HdrSize DIV 4); Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5

1 0

Re (2): Oberon V4 on the Raspberry Pi?
by peter＠easthope.ca 01 Feb '21

01 Feb '21

>From oberon at wildwein.de Mon Jan 11 16:58:16 2021 > Native Oberon was also called S3 (but never V3) and S3 was later renamed ro ETH-Oberon On Tue, 12 Jan 2021 06:38:22 +1030 "Chris Burrows" <chris(a)cfbsoftware.com> wrote: > "Native Oberon is one platform of what was originally called Oberon > System 3 (S3 - it was never called V3) and was later renamed to > ETH-Oberon. Sorry to stress detail but official documents don't hyphenate. Beta/alpha FAQ https://en.wikibooks.org/wiki/Oberon/ETH_Oberon/newfaq#numbering General questions, 2. '... we have renamed "Oberon System 3 " to "ETH Oberon ...' White Paper https://en.wikibooks.org/wiki/Oberon/ETH_Oberon/white "ETH Oberon" is in the title and throughout the document. Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0

Re: [Oberon] SD Card File Exchange
by Chris Burrows 01 Feb '21

01 Feb '21

> -----Original Message----- > From: Skulski, Wojciech [mailto:skulski@pas.rochester.edu] > Sent: Monday, 1 February 2021 3:49 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Re: [Oberon] SD Card File Exchange (was: Why is RSC string > data word-aligned?) > > Chris: > > >"HCFiler - An efficient embedded SDHC FileSystem" > >https://www.astrobe.com/forum/viewtopic.php?f=4&t=534 > > I know. It is great! > > >Copying files from Windows using HCFiler has not been a high > priority > >for me as nobody apart from you has asked me for it to date. Is > there > >anybody else here who is interested? > > I would ask an opposite question. Why the RISC5 OS should not adopt > the HCFiler as an official file system? > There are many reasons why it is not suitable as the file system for RISC5 OS. For starters it is sequential access only - not random access. Think of it as like writing data to a tape drive. It is designed to be used to stream continuous data to / from the SD card, such as might be used in a data-logging application. Hence it is useful for transferring files from one system to another or for backing up a set of files, but could not be used, for example, with a text editor. Chris

2 1

Re: [Oberon] SD Card File Exchange (was: Why is RSC string data word-aligned?)
by Chris Burrows 01 Feb '21

01 Feb '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Skulski, Wojciech > Sent: Monday, 1 February 2021 7:00 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Why is RSC string data word-aligned? > > From my user perspective the file system speed optimizations are not > even secondary. I would rather want to see a convenient file exchange > between the RISC5 Oberon and Windows workstations. I would like to > plug the Oberon SD into an SD card reader and easily copy files under > Windows, from the V4 directory to the SD and vice versa, using the > usual Windows drag and drop. I would like to do the same between the > Oberon SD and the emulator. > As you are aware, our HCFiler (high-capacity) software allows you to plug the Oberon SD card into an SD card reader and copy files to Windows. For the benefit of others, the original announcement is here: "HCFiler - An efficient embedded SDHC FileSystem" https://www.astrobe.com/forum/viewtopic.php?f=4&t=534 The source code that is available to copy the files from the Project Oberon partition to the HCFiler partition (ALL of the SD card, no matter how big) is available. It would not be difficult to adapt this to copy files from Windows to the Project Oberon partition. I would recommend using Gardens Point Component Pascal as the compiler to do this: https://www.cfbsoftware.com/gpcp GPCP and CPIde is what I use daily for all of my Oberon development under Windows 10. > I would like to use the entire SD card rather than a small portion of > it. I do not mind "partitions", if partitions are visible and easily > used under the emulator, the Windows host, and the Oberon > workstation. > I would like to add Linux and Mac to the list of hosts, > though I am not using either. > I'll leave it to others to recommend solutions for emulators and Linux and Mac. > Present PC link is fine for small files or for the SW development. > But it is not great for massive file exchange between Oberon and > hosts, or Oberon and emulators. > Copying files from Windows using HCFiler has not been a high priority for me as nobody apart from you has asked me for it to date. Is there anybody else here who is interested? > Concerning the speed under the Oberon, a boost would be provided with > the QSPI interface rather than the present SPI interface. Point me to documentation on how to access SDHC cards using QSPI and I'll look into it. I was only aware of MMC as a faster access method. If anybody has any experience of using MMC with RISC5 I'd be very interested. Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5

2 1

List of extensions for Project Oberon compiler
by August Karlstrom 01 Feb '21

01 Feb '21

Does anyone know if the language extensions that the Project Oberon compiler provides in relation to the Oberon report (from 2016) is documented somewhere? I'm thinking of features such as dynamic arrays and structural equivalence of arrays used in assignments. -- August

5 9

Why is RSC string data word-aligned?
by Andreas Pirklbauer 31 Jan '21

31 Jan '21

> The unaligned data in a .rsc file is, I agree, unfortunate, as it could > have been aligned relatively easily and then data could have been > copied into memory a word at a time. Isn’t any data - including string data . already word-aligned in the compiler (and therefore also in the .rsc file)? 1. The array ORG.str itself is word-aligned, because... - Modules.AllocPtr is word-aligned (see Modules.Load) - Modules.DescSize is a multiple of 4, so mod.data is word-aligned - All type descriptors are word-aligned (see ORG.BuildTD) - All variables are word-aligned (see ORG.Declarations) - All strings are word-aligned (see ORG.MakeStringItem) 2. ORG.MakeStringItem WHILE strx MOD 4 # 0 DO str[strx] := 0X; INC(strx) END 3. ORP.Declarations IF sym = ORS.var THEN ... IF tp.size > 1 THEN varsize := (varsize + 3) DIV 4 * 4 (*align*) END ; … END ; varsize := (varsize + 3) DIV 4 * 4;

6 7

Why is RSC string data word-aligned?
by Colby Russell 31 Jan '21

31 Jan '21

I'm returning to some of the code that deals with Oberon's RSC binary file format. The first time I went through this exercise, I noticed that ORG pads string data, so individual strings begin on word boundaries, and I didn't think much about it. Presumably it was done for efficiency. Now, though, I'm wondering. Does anyone have a breakdown comparing the two approaches--where strings don't get padded with NUL bytes and may begin anywhere, versus what happens if with word alignment? If there are some string handling routines where this makes a material difference, can someone point to them? I've already looked around, but I realize that string representation is a cross-cutting concern, and there's just too much material to exhaustively scour it all again. If there was a call out on this topic in the explanation of the the simple compiler that's documented in Compiler Construction, then I wasn't able to find it. I looked at a few sections in the Oberon book as well, hoping to see if it was explained (e.g. the module loader chapter), but didn't spot anything there, either. -- Colby Russell

6 11

Why is RSC string data word-aligned?
by Andreas Pirklbauer 31 Jan '21

31 Jan '21

> However, the whole object file is read in when the module is loaded. Hence, > the module loader is only slowed down by 1% because of those extra nulls. Perhaps not even 1% slower, because consecutive bytes are read from in-memory buffers.

1 0

Re: [Oberon] Why is RSC string data word-aligned?
by Jörg 31 Jan '21

31 Jan '21

Hi Colby > No. To repeat: I'm talking about CPU instructions and memory reads--i.e. Okay. So, what exactly do you want to optimize? - write IO commands - read IO commands - memory accesses - CPU cycles All of the above is not equivalent. And might result in different code. Normally, such kind of micro optimization is done in the inner most part of a loop that is called million of times. (ray tracing or so) rsc file writing and reading does not happen very often. >> To optimize the File IO you would turn this [...] into something like this >I'm not sure where that sample comes from. It doesn't match the code in the module loader (and it wouldn't make sense; the module loader is doing a file read, not a write). This is the code in the compiler, where strings are written to the rsc file. And my attempt to optimize file write IO in the compiler, when writing the rsc file. My code does for sure less file write IO but is longer than the original. I can't immediately judge whether overall less CPU cycles are the result of my code compared to the original simple FOR. File write is buffered and is very efficient as it normally involves only two IFs and 3 assignments per Write() call. The read in the module loader would obviously be the opposite: when reading the eos (=0X), we have to expand it to consecutive 0X to be word-aligned. br Jörg

1 0

Re (2): Oberon genealogy graph
by peter＠easthope.ca 23 Jan '21

23 Jan '21

The genealogy diagram is revised again, primarily to remove ambiguous arrow crossings and to represent chronology better. https://en.wikibooks.org/wiki/Oberon#Historical_Perspective I think of two potential criticisms. (1) The diagram is too complex and bulky. Visualization is hampered. (2) Out of respect for original work, development beyond Oberon-07 and V5 should not be included. Both can be addressed by dividing the diagram into smaller diagrams. For example, derivatives beyond Oberon-07 and V5 can be in a second graph. Feedback in the list or in personal email is welcome. Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0