[Oberon] Negative integer literals in Oberon

[Jörg]

August

Did you ever write a display driver in Oberon? It can obviously be done but the code is full of strange code (SYSTEM.VALs, Strange SETs and INTEGER constants that have nothing to do with neither INTEGERs nor SETs..) The whole code is heavily compiler dependent not Oberon dependent.

ASSERT (0FFFFFFFF = -1) should never be true. as per report left side is positive, right side is negative. Thus is heavily compiler dependent.

Jörg

> Am 27.04.2020 um 20:22 schrieb August Karlstrom <fusionfile at gmail.com>:
> 
> On 2020-04-27 15:12, Jörg wrote:
>> Puristically speaking, Oberon can't be used for low level programming
>> as too much things are left to the implementation. 
> 
> I don't think I agree. As mentioned by Chris, in a low-level module you can assert that the type INTEGER has the desired properties and then assume that the requirements are met in the rest of the code:
> 
>    ASSERT(SYSTEM.SIZE(INTEGER) = 4);
>    ASSERT(0FFFFFFFFH = -1) (*require two's complement*)
>    ...
> 
>> An abstraction like "BITFIELD" or "BIT32" or so is missing. This new
>> base type is not identical to INTEGER as it does not leave the
>> implementation open, but defines exactly how bits are numbered, and
>> how many bits there are. If you use the base type INTEGER where you
>> basically want to manipulate bits, these two concepts clash. On this
>> bit type you can use bitwise AND, OR, XOR, can shift etc.
> 
> The basic philosophy of the Oberon language report is to describe an abstract language which does contain references to a computer or computing mechanism. This makes the language timeless. In the future 32-bit computing will probably be completely outdated.
> 
> 
> -- August
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon