[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exceptions and SYSTEM definition



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

All parts were "stolen" from the Ofront (Oberon-2 to C) translator, so
I didn't invent anything.  Dr. Templ can be blamed if you don't like his
implementation.
 
> 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.

Very well, the logical place to put this stuff, aside from SYSTEM, would be 
in the Oberon-2 Kernel module which performs memory allocations and garbage 
collection.
 
> >  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.

It's actually a UNIX blurb.  I think every micro under the sun will be able
to generate such an exception so I don't think this is system dependent.  The
alternative of defining an unused exception for our use _would_ be very system
dependent.
 
> >  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.
> 
> 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?
 
> 
> 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

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

Michael G.