[Oberon] Negative integer literals in Oberon

[Joerg]

Dave

For smaller values than the size of your CPU register it‘s not needed, as you always can enfoce what you want by using normal INTEGER arithmetic.

b := FFH;
word16 := 0CAFEH;

or to be absolutely sure (although not needed)

b := FFH MOD 100H;
word16 := 0CAFEH MOD 10000H;

All those literals are legal INTEGERs on a 32 CPU.

But you can‘t use the same for values completely filling yor register that are no valid INTEGERs anymore.

i := 0CAFEBABEH;
is not going to work, as CAFEBABE needs more than 31 bit to be represented as positive INTEGER.

br
Jörg

> Am 02.05.2020 um 16:19 schrieb dave at brownsmeet.com:
> 
> Yes, that seems good.
> 
> Personally I am surprised there is not more support in compilers (of all languages) for generating run time integer overflow checking code.
> 
> In my Pascal days I got into the habit of using subranges rather than INTEGER pretty much everywhere, and caught quite a few mistakes. It seems highly likely that I have not stopped making such mistakes since using languages without integer range checking :-(.
> 
> Re suffix characters and the number of integer types - it seems to me that we should solve for more sizes - there is a lot of data that is composed of sequences of 8 bits, and 16 bit data exists too. If our solution involves suffices at all, then I would like to see HEX suffixes available for all 4 sizes.
> 
> Cheers -- Dave.
> 
> 
>> On 2020-05-02 12:59, Joerg wrote:
>> Dave
>> Let’s assume we are on a 64bit CPU and we have two integer types:
>> INTEGER (32bit) and LONGINT (64bit)
>> In my point of view, you would need two value cast operators H and L
>> to cover those cases.
>> But in additiion to the H and L thingy, the compiler might make a
>> difference between
>> SHORT(long) and
>> SYSTEM.VAL(INTEGER, long)
>> SHORT could generate a runtime error.
>> SYSTEM.VAL most probably not as it is low level and most compilers
>> implement this just as
>>   long MOD 100000000L
>> br
>> Jörg
> /oberon