Subject: Re: SDL-News: Previous Nextstate Symbol
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Wed Sep 03 2003 - 15:51:02 GMT
Become an SDL Forum Society member <http://www.sdl-forum.org/Society/members.htm>
The originator of this message is responsible for its content.
-----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews -----
Peter Heath at Peter.Heath#motorola.com wrote on 02/09/2003 02:33:
> Become an SDL Forum Society member
> <http://www.sdl-forum.org/Society/members.htm>
> The originator of this message is responsible for its content.
> -----From Peter Heath <Peter.Heath#motorola.com> to sdlnews -----
>
> Hi,
> I would like to clarify a point in the SDL standard....
> Scenario:
> If I am in a state in a process and upon receipt of
> a signal, call a procedure that itself
> has a state included, and then on exit go to the previous
> nextstate (dash symbol), what should be the final state?
> 1. The previous state of the process..
> 2. The previous state of the procedure..
>
> The standard does not seem clear on this point, unless I
> have not found the correct place.
> Thanks,
> Peter Heath
> Adelaide, Australia
>
> --End text from Peter Heath <Peter.Heath#motorola.com> to sdlnews ---
> For extra SDL Forum Society benefits join at
> <http://www.sdl-forum.org/Society/members.htm>
> 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
Dear Peter,
The answer given by Fabrice is essentially correct.
You do not return to a state within the procedure.
(If you want this effect you need an implementation of an SDL-2000 composite
state rather than a procedure and a nextstate node with HISTORY!).
However, the details given by Fabrice should be clarified.
What the standard for SDL-2000 actually says is:
11.12.2.1 Nextstate - Model (Page 91)
"In each <nextstate area> of a <state area> the <dash nextstate> is replaced
by the <state name> of the <state area>. This
model is applied after the transformation of <state area>s and all other
transformations except those for trailing commas,
synonyms, priority inputs, continuous signals, enabling conditions, implicit
tasks for imperative actions and remote
variables or procedures."
[[[[
and is the same semantics as Z.100(03/93) for SDL-92, which (4.9 Dash
nextstate, page 104) has:
"In each <nextstate> of a <state> the <dash nextstate> is replaced by the
<state name> of the <state>."
and (7.1 Transformation of additional concepts, rule 18 page 197)
"Dash nextstate is replaced by the state name".
The differences between the SDL-92 and SDL-2000 standards in this case are
only:
1. the rule names which refer to graphical rules for SDL-2000 so have "area"
added;
2. the order of transformation is covered by in the nextstate description in
SDL-2000 and in section 7.1 in SDL-92.
]]]]
So what does the text mean?
The <state area> (or <state> in SDL-92) starts with the <state symbol>
containing the <state name> in a diagram which is associated with the input
or other stimulus that is followed by the transition area that terminates
with the <nextstate area>.
In the most simple case there is one input symbol followed by a simple
transition that is terminated by a dash nextstate. In this case, the dash is
transformed into the name of the state. Note that whether the transition
contains a procedure call is irrelevant and any internal states in the
procedure are hidden.
Of course, this simple case is not very useful because the user could (and
indeed in such cases I would say SHOULD) have just written the state name.
The dash nextstate becomes more useful when the original diagram has more
than one state that can lead to the same dash nextstate. So how does the
standard cover these cases? What happens is that (in theory) the
transformations that are applied before dash nextstate remove the joins
which could lead to this situation. For example, if a transition (t1) from
state S1 joins a transition (t2) from state S2 and after the join there is a
common transition part (tc) terminating in a dash nextstate (dns), this is
transformed into two disjoint transitions S1-t1-tc-dns and S2-t2-tc-dns.
Because the dash nextstate is applied after such transformations there is
always a unique state.
However, I would be very surprised if any code generators actually implement
joins in this way - which is why I added "in theory".
It is more practical to keep a record of the current state, and when the
dash nextstate is encountered return to that state. Obviously when a
procedure is entered the "current state" at the point of call has to be
retained during the execution of the procedure. If the procedure is
recursive, various invocations may be in different states!
It is this practical implementation of the SDL semantics that gives rise to
the notion of dynamic states.
-- Rick Reed - rickreed#tseng.co.uk Tel:+44 15394 88462 Mob.:+44 7970 50 96 50--End text from Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews --- For extra SDL Forum Society benefits join at <http://www.sdl-forum.org/Society/members.htm>
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT