[Oberon] Runtime Overflow Checks

[Chris Burrows]

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
>