Subject: SDL-News: VERILOG Comments on Exception handling
From: Philippe Leblanc (leblanc#tlse.verilog.fr)
Date: Fri Jun 26 1998 - 11:25:21 GMT
The originator of this message is responsible for its content.
-----From Philippe Leblanc <leblanc#tlse.verilog.fr> to sdlnews -----
Here are our comments on the last contribution on the introduction of Exception handling in SDL.
In the new proposed extension for exception handling, the "resume" constructs
and some graphical symbols were suppressed as proposed,
but it seems that other proposals for simplification were ignored.
Here are details about the "hidden processing" problems:
basically , I would like to be able to translate SDL into C code,
and to translate SDL exception mechanisms into C "goto" statements.
(a large part of this text was already present in our 1997 analysis,
new parts are marked with ``*'')
a) I would like to remove the association of exception of handler
to "transitions" (dynamic ones, that end with a nexstate),
as it seems that the scope of such handlers
can not be decided at compile time: if you have two different
handlers associated to two input transitions, and if these transitions
both end with "join" to one "free action" transition, the compiler
does not know which handler is associated to the actions in the "free
action" transition, and then it can not generate a C "goto".
* Implementing the proposed mechanism would add an overhead in execution time
* to every transition, to set and reset flags indicating the current
* active handlers, and would add an overhead in code size to test the flags
* to compute which handler is active.
* These overhead are probably small, but I am more worried by the "overhead"
* in the code generator in the run-time libraries.
b) In fact I suppose that it would be necessary to remove the concept of
implicit dynamic "activation" and "desactivation" of exception handlers:
handlers should be associated statically, according to scope units.
* The concept of "exception scope" should just be a subset of the Z.100 scopes.
Dynamic activation introduces many special rules which make the use of
exception mechanisms difficult to implement AND TO USE (dynamic behavior
is not obvious at all).
[note c) was about RESUME]
d) I would like to remove the "repeat" mechanism, as it implies that the "name"
and the parameters of the last exception caught must be stored for the possible
following "repeat".
This would also be a conflict with the sentence "If no variable is mentionned
for a given parameter position in the exception, the value at this position
is discarded".
Furthermore the same kind of mechanism was proposed for signals,
but was rejected because it was too complex...
Other remarks:
[note e) was about the number of new graphical symbols and new keywords]
* f) As "RETURN <expression>" is the only terminator for which an on-exception
is useful,
* why not making this explicit by making impossibly on-exception for
other terminators ?
*
*g) about propagation of exceptions in exported procedures back to the calling
* process : there might be a visibility conflict, it should be forbidden
* to raise an exception in an exported procedure if the declaration of the
* exception is not visible from the matching "remote" declaration.
*
*h) I did not understand the sentence page 4 "The SDL state is that state, however,
* where the exception is raised" : what does "the SDL state" refers to ?
*
*i) About JOIN:
* - join in <state> or <free action> should not refer to labels
* defined in <exception handler>, otherwise for instance it would
* be possible to reach a REPEAT action while no exception was raised
* (or one would try to deactivate an handler which were not activated)
* - an on-exception should also be deactivated by a join to label
* defined outside any <exception handler>
*
*j) page 6 replace "as well as the supertype" by "as well as the graph inherited
* from the supertype"
*
*
* Note: I did not read in detail the "Other changes implied by exception
handling" section
Yves Lejeune
-- Tel.: +33 (0)5 61 19 29 04 Switchboard: +33 (0)5 61 19 29 39 Fax: +33 (0)5 61 40 84 52 Email: lejeune#verilog.fr VERILOG S.A. BP 1310 F-31106 Toulouse Cedex - France http://www.verilogusa.com-----End text from Philippe Leblanc <leblanc#tlse.verilog.fr> 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