Re: Exceptions and SYSTEM definition

[acken@informatik.uni-kl.de]

>  Date: Mon, 22 Apr 96 10:51:50 EDT
>  From: Mike Griebling <grieblm@trt.allied.com>
>  
>  Hi all,
>  
>  I've done a first pass attempt at defining the SYSTEM extensions required
>  to support exceptions, garbage collection, and finalization.  

Can you identify the parts you took from existing Oberon
implementations and which are `original'?

First a general comment: This file describes an interface to the
runtime system.  It defines a set of variables and procedures.  
These features don't necessarily have to reside in SYSTEM.  They can
IMHO be defined in a standard module and there aren't any performance
considerations that impede this.  The current implementation of SYSTEM
does not implement variables, and SYSTEM procedures are directly
translated into GSA opcodes.  Extending SYSTEM would mean to introduce
some way to handle variables, and to add new opcodes for every
procedure.  Therefore I'd prefer to have the additional features
listed here defined in a standard (or rather `external') module.

>  Here's what I have so far:

>  Following is an explanation of how exceptions will be handled in the OOC compiler in
>  a system-independent manner.  
>  [...]
>  a signal which will be caught by the installed exception handler.  The HALT
>  exceptions "piggy-back" on top of the "ILLEGAL INSTRUCTION" exception and are

Looks like ix86 technical blurb.  This istoo system dependent and
should be reformulated.

>  distinguished by having a SYSTEM.halt value (the argument value of the HALT
>  function) which is not equal to -128.  Assertion arguments are stored in the
>  SYSTEM.assert value so the exception handler can respond to different kinds
>  of assertions.  A typical ASSERT would be defined as:
>  
>  	PROCEDURE ASSERT (c: BOOLEAN; n: LONGINT);
>  	BEGIN
>  	  IF ~c THEN SYSTEM.assert:=n; HALT(-1) END
>  	END ASSERT;
>  
>  An ASSERT with no second argument would assign a default of 0 to SYSTEM.assert.

This adequately describes the behaviour of ASSERT as seen by the user.
The current implemenation of ASSERT looks vastly different (off topic,
I know, but Mike's posting reminded me of writing it down):
An ASSERT instruction is translated by evaluating the boolean
parameter into a value B, adding two guards if-true: B, if-false: B,
and placing an GSA instruction "trap-assert C" into the if-false
guard.  C is the constant value passed as second parameter to ASSERT. 
If not present, the value of Config.defAssertTrap is used.  

There are two reasons why ASSERT isn't modeled as a procedure call:
1) Efficiency.  Saves a call.
2) Boolean reasoning.  The asserted expression is known to hold
afterwards.  This enables further optimizations like removing
redundant runtime checks.  

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. 


Except for the choice of the module name SYSTEM I like the rest of the
specs.  Having explicit finalization procedures for objects will
probably turn out to be a great deal of help when dealing with systems
resources, although it's a vast transgression from the ETH-style
systems. 

-- mva