[Oberon] SYSTEM Modules

[Chris Burrows]

> -----Original Message-----
> From: Jörg Straube [mailto:joerg.straube at iaeth.ch]
> Sent: Monday, 12 November 2018 7:19 PM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] SYSTEM Modules
> 
> In my point BIT is in SYSTEM as it depends on the endianess and hence
> is not portable. This is the difference to bit access via  IN , where
> endianess is of no importance
> 

My understanding is that Richard's proposition was that lack of portability alone was not sufficient to relegate a built-in procedure to SYSTEM. The procedure also had to be unsafe. I concur with that notion.

In any case, endianess is no big deal. It is just one of many issues to be aware of if you are concerned about portability. As well as the traditional concerns about signed / unsigned data, sizes of numeric data, floating point formats etc. Oberon's SET size, character sets etc. are also now implementation-dependent. 

However, anybody who takes the time to understand the issues involved just needs to be alert not alarmed.

> 
> To put BFI in SYSTEM for your ARM compiler is totally okay. As it is
> in SYSTEM everybody understands that code with SYSTEM.BFI has to be
> re-written for another CPU. However I m against putting BFI in an
> RISC5 compiler as ther is no RISC5 instruction. And emulating
> assembler code of on CPU on another CPU is bexond the scope of
> SYSTEM.
> 

Mapping to a RISC5 instruction is not a pre-condition for inclusion in either SYSTEM procedures or built-in procedures. Look at the code generated by SYSTEM.COPY, PACK and UNPK for example. 

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com