[Oberon] Type compatibility in Oberon

[Joerg]

I agree that you have to have a certain freedom in implementation. Eg the whole telecom industry only defines the interface between systems (exact semantic and presentation layer) but not the implementation of this interface.
In Oberon the semantic and syntax is addressed but the presentation layer (key for low level programming) is totally left to the compiler. Most probably NW didn’t want to specify the endianess nor the register size of the underlying HW. That is okay.
But leaving this topic totally to the compiler and not addressing it in the language, is in my point of view, not optimal.
The topic how to solve this dilemma is not easy. How to balance the two sides: on one side being high level and abstract things away and on the other side be low level enough to allow register programming if needed.

Eg define the exact semantic of hex notation would help: Are hex literals totally identical to decimal literals (with INTEGER sign rules) or does hex notation allow to represent 1:1 values of the underlying registers (=neglecting / overwriting INTEGER sign rules and specify the value 1:1 with the underlying endianness)? This must be part of the language.

Bit numbering is another topic that is totally neglected in Oberon. In my point of view it does not hurt to define bit 0 in a SET is the rightmost. As the compiler knows the endianness of the underlying CPU he either maps the bit nbr 1:1 or calculates (register size - bit nbr).

br
Jörg

> Am 01.05.2020 um 11:08 schrieb Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>:
> 
> 
>> 
>> Oberon as it is defined in the report leaves some parts needed for low level programming to the implementation.
> 
> At the heart the problem appears to be two-fold: a) the language leaves certain things undefined, and b) in order to truly implement an entire system like the Oberon system, one has to cheat (at least a little). For example, today it is not guaranteed that a program compiled with two different implementations of the same report behave in the same way.
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon