Summary - looking for state machine languages

A while ago I posted a query concerning state machine languages for
real-time and communications systems. Here's the current list:


        Lex
        YACC
        AACC (event-driven parser generator from alt.sources)
        SDL
        Estelle
        Orwell (defunct)
        FSMDL (Dominic Alston's thesis)
        PROMELA
        SDT (similar to SDL)
        Statemate


I checked the archives of comp.compilers, but didn't find much. If anyone
has any further additions to this list, please let me know. (in
particular, I forgot to post to comp.realtime the first time, so some of
you never saw my first request...)


Anyway, here are the individual responses I got:


  -----


From: hays@ichips.intel.com
Subject: Re: Looking for State Machine languages
Date: Wed, 23 Mar 1994 10:18:55 -0800


Back in 1984, I developed a state machine language called "Orwell" (yes,
a horrible pun on "1984" and "state"), that was used at Infomed
Corporation (now defunct) to code real-time data collection modules,
and modem, network, and database protocols.


It is now defunct, and I don't even have a language specification,
anymore.


Basically, the language allowed the definition of "states", "inputs",
and "actions."


The "actions" clause was interesting, as one of the built-in actions was
the spawning of new state machines, either staticly specified, or that
had been sent in the input text.


Doing this allowed us to dynamically update the networking code, and
to create new kinds of queries to the database engine on the fly.


Interestingly enough, one is seeing the reappearance of this sort of
"active data" idea in many of the PDA's being developed today.


There is nothing new under the sun.


Statically specified state machines were compiled to optimized machine
code, while dynamically specified state machines were compiled to an
intermediate representation, with an "action" that could force
compilation to optimized machine code, for performance.


Default and non-default error states could be specified.


The resulting code was rommable, and could be linked with PL/M-86
compiled code, as well.


Regards,
Kirk Hays


  -----


From: "Kirk Hays" <hays@ichips.intel.com>
Subject: Re: Looking for State Machine languages
Date: Thu, 24 Mar 1994 13:59:18 -0800 (PST)


> This sounds very much like the sort of thing I'm looking for. You
> didn't happen to publish anything about it, did you? Oh well.


Nope, sorry, it was strictly a proprietary language, we never had more
than about 20 people programming in Orwell.


The language manual was about 5 xeroxed sheets explaining the syntax
and semantics, plus an online example or two. I'll poke around up in
the attic, and see if I can find anything.


Basicly, we found that this approach allowed "more correctness" to be
built into state machines than could be had by coding them in
imperative languages.


> [It seems like "language-based" approaches like this have gone out of
> favor, and the fashionable thing to do nowadays is to have a fancy
> bubble editor with a lousy code generator that's always a few releases
> in the future. But I digress...]


These things go in cycles...


Regards,
Kirk


  -----


From: dominic alston <da16@unix.brighton.ac.uk>
Date: Thu, 24 Mar 94 15:49:46 GMT


Subject: Re: Looking for State Machine languages
Newsgroups: comp.lang.misc,comp.protocols.misc,comp.compilers
Organization: University of Brighton, UK


I am working on a project as part of BSc (HONS) in computer science which
involves the simulation of object charts (hierarchical finite state machines).
I am presently working on the parser for my language FSMDL (used to define a
model). FSMDL introduces a form of state inheritance (superclass relationship),
from which states can be instances of a 'state class'.


The tool will eventually run under MS Windows 3.0 from which the model can
be edited and simulated. Simulation will result in OID (object interaction
diagram) production.


You might want to look at PROMELA, a finite state based language by Gerard
Holzmann, or YACC (part of the same family as lex).


--
Dominic Alston


  -----


From: dominic alston <da16@unix.brighton.ac.uk>
Subject: Re: your mail
Date: Fri, 25 Mar 1994 11:58:35 +0000 (GMT)


> It sounds interesting. How close is the relationship between
> statecharts and object charts?


Very close, object charts are extensions of state charts.


> You wouldn't happen to have a reference at hand for PROMELA?
[...]


It is documented in Gerard Holzmann's book - Design and validation of
computer protocols. It is also available free from AT&T netlib archives.


--
Dominic Alston


  -----


From: Baard Bugge <Baard.Bugge@nta.no>
Subject: Re: Looking for State Machine languages
Date: Thu, 24 Mar 1994 12:57:56 +0100


We are currently using SDT which is a tool for drawing SDL-diagrams
and generating C-code from the diagrams. The system we are making
is a protocol-converter, very 'communication' and very 'real-time'.
We are happy with the tool (SDT).


We also considered using C++. Some find it strange, but a C++ object
is really a FSM and in a multithreading environment several of these
FSM's can run concurrently. We tried this in Windows NT and it
works. Tools for generating C++ class sceletons from State diagrams
exist.


Other Object-oriented languages (such as Eiffel) can aslo be used
although some languages have problems with running objects concurrently
(work is being done on Eiffel).


--
Baard Bugge
Norwegian Telecom


  -----


From: bet@std.sbi.com (Bennett Todd)
Subject: Re: Looking for State Machine languages
Date: Tue, 29 Mar 1994 19:12:00 -0500 (EST)


Many years ago I designed a state-machine language, which I called logonto,
for specifying logon dialogues to connect through modems, terminal servers,
etc. Several other people made good use of it at the time; there was a
PC-based email system, and a Unix-based facility for printing onto IBM
mainframe printers by way of logging in and kermit-ing the file up!


But a couple of years ago I ran into expect(1), and realized that it
completely obsoleted my language. I can't recommend it too highly.


                ftp.cme.nist.gov:~ftp/pub/expect


-Bennett
bet@sbi.com


  -----


[missing message - Bill Martin suggests YACC]


  -----


From: "Bill Martin" <MARTIN@novell.wd.cubic.com>
Subject: Re: Looking for State Machine languages
Date: Wed, 23 Mar 1994 14:41:14 PST


> An interesting idea. At least you get event names that aren't
> restricted to one character. (check out the file ckcpro.w in the
> kermit source sometime - it's pretty gross.)
>
> However, I still worry that Yacc, like Lex, might make it too easy to
> write specific code for individual inputs and outputs, rather than
> forcing (actually, "leading" would be better) you to define and code
> inputs and outputs separately, and then write your state machine in
> terms of these abstract inputs and actions.
>
        Its a lot more than just "nice names" for events...you can
specify sequences of events which are required to complete a legal
"sentence" of input events, with looping in intermediate states,
actions in intermediate states, etc. I do my own "lexer" to gather
tokens from the external world, some of which are derived from
received serial data from other pieces of hardware, some of them are
from a timer-scanned set of front panel switches, some are from
hardware timer expirations, etc. I find that specifying the high-
level design in a formal grammer is very helpful in getting the
design correct before diving into coding and testing! Now you know
what kind of a bug you are looking for...its not that you have
correctly coded a flawed design, for example, but you just screwed up
the implementation!
        About the forcing/leading issue...thats kind of like legislating
morality, really. Its no big trick to do lousy work in any language,
no matter how restrictive it is.


Bill
-Bill-
martin@cubic.com
(619) 627-4516


  -----


From: Mark Stambaugh <stambaug@spk.hp.com>
Subject: Looking for State Machine languages
Date: Fri, 25 Mar 1994 10:58:50 -0800


Statemate by I-Logix is quite good.
--------------------------
Mark Stambaugh
stambaug@spk.hp.com
Telnet: 921-3432
Bell: (509) 921-3432


  -----


Peter Desnoyers
--
--

Return to the comp.compilers page.
Search the comp.compilers archives again.