[Oberon] Negative integer literals in Oberon

Joerg joerg.straube at iaeth.ch
Sat May 2 17:12:19 CEST 2020


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.

is not going to work, as CAFEBABE needs more than 31 bit to be represented as positive INTEGER.


> 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
>> 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

More information about the Oberon mailing list