[Oberon] SYSTEM.COPY (was: Compiler behaviour for a32 := a8)

Chris Burrows chris at cfbsoftware.com
Mon Feb 1 20:51:01 CET 2021


> -----Original Message-----
> From: Hans Klaver [mailto:hklaver at 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




More information about the Oberon mailing list