[Oberon] Negative integer literals in Oberon
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.
i := 0CAFEBABEH;
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:
>> 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
More information about the Oberon