[Oberon] Runtime Overflow Checks

[Joerg]

BTW: according to the RISC5 architecture guide overflow bit is only set with ADD/SUB not with multiplication, as the high part of the multiplication is stored in H register.

Your loop works if you use  INC(j, j)

Jörg

> Am 03.05.2020 um 13:43 schrieb Chris Burrows <chris at cfbsoftware.com>:
> 
> Thanks Jörg that's useful to know. I did wonder what SYSTEM.COND was intended to be used for.
> 
>> -----Original Message-----
>> From: Jörg [mailto:joerg.straube at iaeth.ch]
>> Sent: Sunday, 3 May 2020 7:58 PM
>> To: chris at cfbsoftware.com; ETH Oberon and related systems
>> Subject: Re: [Oberon] Runtime Overflow Checks (was: Negative integer
>> literals in Oberon)
>> 
>> Chris
>> 
>> Such a hidden feature does exist in the Oberon-07 compiler as well:
>>    i := 47000;
>>    i := i * 47000;
>>    IF SYSTEM.COND(0) THEN Out.String("overflow"); Out.Ln END;
>> 
>> The parameter is the condition you like to check.
>> 
>> The case above could be catched with this as well
>>    IF i < 0 THEN Out.String("overflow"); Out.Ln END;
>> 
>> br
>> J�rg
>> 
>> ?Am 03.05.20, 02:22 schrieb "Oberon im Auftrag von Chris Burrows" <oberon-
>> bounces at lists.inf.ethz.ch im Auftrag von chris at cfbsoftware.com>:
>> 
>>> -----Original Message-----
>>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>>> dave at brownsmeet.com
>>> Sent: Saturday, 2 May 2020 11:49 PM
>>> To: ETH Oberon and related systems
>>> Subject: Re: [Oberon] Negative integer literals in Oberon
>>> 
>>> Personally I am surprised there is not more support in compilers (of
>> all
>>> languages) for generating run time integer overflow checking code.
>>> 
>> 
>>    Inevitably run time integer overflow checking code leads to an impact on
>> performance. Assuming that such an impact is considered to be acceptable,
>> the next question is: What should a runtime system do when it detects an
>> integer overflow? Some might say it should cause an application to come to
>> an abrupt halt in mid-flight. That is not always desirable behaviour.
>> 
>>    To be palatable, systems that do generate runtime integer overflow
>> checks also need to allow the programmer to disable them. If the checks can
>> be turned on and off at will it becomes more difficult to verify that the
>> application is correct. Hence, the scope of such switches must be as local
>> as possible e.g. a single statement.
>> 
>>    An alternative solution is to give the programmer a means to detect when
>> overflow has occurred rather than generating runtime overflow checks by
>> default. The programmer would have a much better idea than the compiler
>> implementer of when they were required and the best course of action to take
>> when they were detcted. One example I have seen of this was in Wirth's
>> Oberon-07 ARM compiler. This had an additional function SYSTEM.OVFL. My
>> understanding is that this returns TRUE if the previous assignment generated
>> an overflow condition that was detectable by the hardware. E.g. you could
>> write something like:
>> 
>>    (* untested! *)
>>    j := 1;
>>    FOR i := 1 TO 128 DO
>>      j := j * 2;
>>      IF SYSTEM.OVFL(j) THEN Out.String("Size of INTEGER in bits = ");
>> Out.Int(i, 0) END
>>    END;
>> 
>>    Regards,
>>    Chris Burrows
>>    CFB Software
>>    https://www.astrobe.com
>> 
>> 
>> 
>> 
>>    --
>>    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>    https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon