[Oberon] Type compatibility in Oberon

[Guy T.]

>Why didn‘t you skip the difference between LONGINT and INTEGER and treat all values as 64 bit INTEGERs?
>Because of code size, because of performance...
>Jörg

Both. The need to use 64 bits integers is limited (to what I can see right now) to clock timing manipulations. On a 32 bits RISC machine, that means double use of registers to manipulate the information, that triple the amount of instructions to execute the same operations as with 32 bits values. It would impair everything else in a limited resource platform.

>> Am 02.05.2020 um 15:40 schrieb Guy T. <turgu666 at gmail.com>:
>> 
>> I’m currently implementing 64 bits LONGINT on a 32 bits processor. Main reason is related to the internal clock micro-seconds information returned by the hardware using 64 bits. I’m using “L” suffix to supply LONGINT hexadecimal constant values. When a decimal constant is defined, if it is too big to fit in an INTEGER, it is then considered to be a LONGINT. A decimal LONGINT constant cannot be negative unless it is part of an expression in the declaration (from the parsing process in the compiler expression() function). 
>> 
>> LONGINT implementation on a 32bit CPU is a good challenge but doable…
>> 
>> Guy