[Oberon] Negative integer literals in Oberon

[Jörg]

> Am 26.04.2020 um 13:52 schrieb August Karlstrom <fusionfile at gmail.com>:
> 
> On 2020-04-26 11:14, Joerg wrote:
>> In earlier Oberon versions, variable integer size was supported: INTEGER and LONGINT. LONGINT is not officially supported in Oberon-07 but the compiler internally declares TYPE LONGINT = INTEGER.
>> The concept of variable integer size is not supported in Oberon-07 anymore. Every INTEGER has one (implementation dependent) size, be it 16 or 32 or 64 or ...
> 
> In principle a compiler could use arbitrary-precision arithmetic for the numeric types.

Right. My main topic is that the literal 90909090H is not negative, it defines the lowest 32 bits of a value. It happens to be interpreted as negative integer, if the implementation uses a presentation layer to represent INTEGERs with 32 bit and uses the MSB to mark negative integers. That’s - as you pointed out - not a given.

>> If you use the hex suffix H to fill up the bits of the underlying INTEGER, you need to know the INTEGER size and are per definition in the grey, non-portable, implementation-dependent area of coding
> 
> As far as I understand, the large hexadecimal literals we are discussing here are typically used for addresses in low-level modules, and when implementing such a module you need to assume a few things about the implementation and the system, so general portability is not to be expected anyway.
> 
The crux of the H suffix is, that it has semantically two flavours: one that just represents an INTEGER in a hexadecimal notation;  instead of 30, write 1EH for whatever reason this might be needed. So its usage is linked to INTEGERs.
The other flavours is rather for low level programming where you need certain bit mask, filters, bit constellation. Has nothing to do with INTEGERs, just a collection of bits. Sometimes SETs could be used here. Puristically, this H usage should be in SYSTEM to clearly mark its non-portablility

Jörg