Special State

Subject: Special State
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Jan 15 2003 - 02:50:25 PST

Hi all,

taken from the minutes with the intent to start a (hopefully small discussion on this).

"Warmke, Doug" wrote:

> ...
>
> Joao explains some details on special states, such as starting
> and accepting state. (e.g. starting state in Joao's implementation
> is always '0', and accepting state is always '1').
>
> Francoise: States 1 and 2 not portable across simulators?
>
> Joao: This stuff is totally implementation dependent, may even
> vary inside one implementation.
>
> Michael: Not very comfortable with the limited identifiability
> of various accepting states (since they are always '1').
>
> Joao: Yes we need to discuss that before moving on much further.

I think it is essential to have the capability to identify such states. As such I am not happy in leaving this up to a vendor (which
might result in non-portable code). I further believe:
 * At a minimum we need to be able to _identify_ the start and any accepting state
 * I would further like to be able to distinguish different accepting states
    (would it be possible to request a list/description of each accepting state ... ?)
I think possible ways to do this is by enforcing a special encoding on the state info; e.g.
 - start state must always be 0
 - accepting state is an integer number between 0x00000001 and 0x7fffffff or'd with 0x80000000, or have the bit 0 set, others not,
or ... or ...
 - non-accepting state is an integer number between 0x00000001 and 0x7fffffff
or have two functions
 - bool svaIsStartState( StateID )
 - bool svaIsAcceptingState(StateID )
or any mixture of this; e.g.
 - Start state is always encoded as 0
 - Accepting states can be identified by bool svaIsAcceptingState(StateID )

Also, what about a function char* svaGetStateDesc( StateID ) that provides a textual description of an (not neccessarily ???
accepting) state? This might be useful information (but really information only, I DON'T think we should standardize the return
format at all).

Just some wild ideas.

-Michael 

--

NOTE: The content of this message may contain personal views
      which are not neccessarily the views of Motorola, unless specifically stated.

         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Software Technologist       Fax: +49-89-92103-680 |( \
    / / | Motorola, Semiconductor Products, System Design   | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@motorola.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

The information contained in this email has been classified as:
Motorola General Business Information (x)
Motorola Internal Use Only            ( )
Motorola Confidential Proprietary     ( )

*** This note may contain Motorola Confidential Proprietary or
    Motorola Internal Use Only Information and is intended to be
    reviewed by only the individual or organization named above.
    If you are not the intended recipient or an authorized representative
    of the intended recipient, you are hereby notified that any review,
    dissemination or copying of this email and its attachments, if any,
    or the information contained herein is prohibited. If you have received
    this email in error, please immediately notify the sender by
    return email and delete this email from your system.
    Thank you! ***

This archive was generated by hypermail 2b28 : Wed Jan 15 2003 - 02:50:58 PST