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