[Oberon] SYSTEM Modules

[Jörg Straube]

Chris I like your list.

Normally, memory access should be done with pointers as theses have a type. Now, if you allow unqualifed GET, it could be seen as untyped memory access.

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

You correctly pointed out that in the past 1byte items were incorrectly declared as CHAR with al pros and cons of the character encoding. As the underlying HW supports items of 1byte and 4byte, NW allows BYTE now as standard numeric type to represent 1byte items and you can do arithmetic on it.

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.

Jörg

Am 12.11.2018 um 08:53 schrieb Chris Burrows <chris at cfbsoftware.com>:

>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Richard Hable
>> Sent: Monday, 12 November 2018 1:13 AM
>> To: oberon at lists.inf.ethz.ch
>> Subject: Re: [Oberon] SYSTEM Modules
>> 
>>> The definition of SYSTEM has diminished over time to the point
>> where
>>> it is now almost redundant.
>> 
>> If this has happened, we should try to make the distinction clear
>> again...
>> 
> 
> Agreed. If SYSTEM is restricted to unsafe and not just non-portable then the distinction is somewhat clearer.
> 
> 1. PUT and COPY are undeniably unsafe.
> 
> 2. ADR and GET are readonly so they are not inherently unsafe. However, they are required for PUT and COPY to be effective so they are unsafe by association.
> 
> 3. VAL falls into the category of it depends ...
> 
> SYSTEM.VAL(SET, intval), SYSTEM.VAL(CHAR, intval), SYSTEM.VAL(INTEGER, charval) are as harmless as ORD and CHR. All are inherently non-portable however.
> 
> On the other hand, SYSTEM.VAL(INTEGER, pointerVal) is as unsafe as ADR.
> 
> 4. BIT and SIZE I'm not so sure about. They are both readonly so I can't see how you could corrupt a system with their use.
> 
> 5. BYTE used to be SYSTEM.BYTE but has now been promoted to be unqualified.
> 
> 6. ASH used to be unqualified at the same time as ROT and LSL were SYSTEM procedures. I always thought that was somewhat inconsistent. They are now replaced with ASR, ROR and LSL. None of which need to be qualified by SYSTEM.
> 
> Considering all of that I believe that the BFI and UBF bitfield procedures I am proposing to introduce are no more unsafe than ASR, ROR and LSL. Consequently they should not need to be qualified with SYSTEM.
> 
> Now the language report explicitly accepts that 'individual implementations may include in their module SYSTEM additional definitions'. So adding these is not considered 'changing the language'. What I am not so sure about is whether the inclusion of additional non-system built-in procedures like BFI, UBF, BITS (i.e. SYSTEM.VAL(SET, intval)) would be considered to be 'changing the language'.
> 
> However, as the language report freely admits that the RISC5 compiler includes the addition non-SYSTEM functions UML, SBC, ADC and LED that leads me to assume it that it is OK for others to do so as well - presumably as long as they are clearly documented as 'implementation-specific extensions'.
> 
> Regards,
> Chris Burrows
> CFB Software
> http://www.astrobe.com
> 
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon