Re: Exceptions and SYSTEM definition

[acken@informatik.uni-kl.de]

>  Date: Tue, 23 Apr 96 06:53:44 EDT
>  From: Mike Griebling <grieblm@trt.allied.com>
>  
>  ...
>  > Even if assertions are disabled, the above described code is
>  > generated, although the trap-assertion instruction has the
>  > `instrIsDisabled' flag set.  It is assumed that the boolean expression
>  > holds nevertheless, allowing the above mentioned optimizations.
>  > Therefore it's possible to enhance the generated code by using
>  > assertions that highlight restrictions of values the compiler normally
>  > doesn't know about.  This is also true if assertions are disabled. 
>  
>  I'm afraid I don't follow you here.  What do you mean in your second last
>  sentence?

Example:
  PROCEDURE P (x: SomePointer);
    BEGIN
      ASSERT (x # NIL);
      x. field := 0;
      ...
    END P;

The front-end emits code for the dereference that is flag with
`instrCheckNIL', telling the back-end to insert a runtime check that
compares `x' to NIL.  But after the assertion it is known that `x'
holds a non-NIL value.  Therefore all following tests can be removed.
In this example the assertion introduces a piece of knowledge about
the possible values of `x' that wouldn't be available without it.

Even if assertions are disabled, this information is part of the code.
The idea is that an assertion guarantees that its boolean parameter
holds, regardless if code is generated to test it or not.

>  Why do say that?  The ETH PowerPC compiler has support for finalization.
>  And as pointed out above, Ofront also supports finalization.

Ok.  I'm overruled.

-- mva