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

[Chris Burrows]

> -----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