[Oberon] Runtime Overflow Checks (was: Negative integer literals in Oberon)

Jörg joerg.straube at iaeth.ch
Sun May 3 12:28:01 CEST 2020


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;


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
    Chris Burrows
    CFB Software
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems

More information about the Oberon mailing list