Re: SDL-News: Re: VERILOG Comments on Exception handling


Subject: Re: SDL-News: Re: VERILOG Comments on Exception handling
From: Martin v. Loewis (loewis#informatik.hu-berlin.de)
Date: Sun Jun 28 1998 - 09:39:15 GMT


The originator of this message is responsible for its content.
-----From "Martin v. Loewis" <loewis#informatik.hu-berlin.de> to sdlnews -----

> That means than when the compiler generates code for a statement,
> it knows which exception handler is concerned if an exception is raised
> by the statement.

In C++, the compiler doesn't know what exception handler is invoked,
as this depends on the dynamic call stack. This is where the power of
exception handling really is: To process an exceptional situation even
when you don't know in advance where it occurs.

> This is another point: my remark was about the overhead of exception handling
> when you use them, not when they are not used.

If I understand your previous message correctly, you propose to drop
features from the current proposal (i.e. not allowing exception
handlers for inputs). If that is the proposal, a user doesn't gain any
performance advantage from it: If the feature is not used (i.e no
handlers for inputs), a code generator could detect that and generate
code as efficient as if you'd drop the feature alltogether.

> In other words, I think that everywere in your proposal when you state
> that a NEXTSTATE deactivates an exception handler, you should state
> that JOIN deactivates the exception handler too, and activates
> the exception handler visible from the joined label.
> It has the same meaning as removing the dynamic activation/deactivation
> concept.

This would be very confusing to users, as a JOIN in SDL does not
really change the state at all. In fact, GR editors often perform
equivalent transformations introducing JOINs.

As a matter of fact, you can transform an SDL specification so that
you know statically, for each action, which exception handlers are
active. This works similar to the transformation of <dash nextstate>
or the state expression (and is performed as a part of dash nextstate
transformation).

Your implementation is free to perform this transformation, if compile
time knowledge of active handlers is required. It seems to me that
*not* performing this transformation would result in more efficient
code, though.

Regards,
Martin

-----End text from "Martin v. Loewis" <loewis#informatik.hu-berlin.de> to sdlnews -----
For help, email "majordomo#sdl-forum.org" with the body of your email as:
    help
or (iff this does not answer your question) email: owner-sdlnews#sdl-forum.org



This archive was generated by hypermail 2a23 : Sun Jun 16 2013 - 10:41:40 GMT