comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <rieachus@comcast.net>
Subject: Re: Hierarchical States Machines
Date: Thu, 29 Apr 2004 01:14:11 -0400
Date: 2004-04-29T01:14:11-04:00	[thread overview]
Message-ID: <cuCdnQ-6gqW-Eg3dRVn-tA@comcast.com> (raw)
In-Reply-To: <k3%jc.11226$lz5.1111351@attbi_s53>

Steve wrote:

> I don't have anything against using goto's for state machines... but...
> 
> I usually set up an enumeration for each state...
> 
> In my opinion it makes things easier to follow since the entry
> to a new state always happens from the same place.

Exactly.  My point is that this:

loop
   case State is
     when...
   end case;
   -- post processing
end loop;

...is the real underlying structure, and you should use gotos when 
needed to preserve it.  Randy mentioned one such case continue. (His 
code looked exactly like a FSM to me, even if he wants to call it 
something else.)  Other typical patterns you run into are where you need 
  multiple exits from the loop, or you need to return to the beginning 
while skipping the post-processing.  For example in the Ada parser 
driver I wrote for state machines created by LALR1 on Multics, there 
were some "merged" state entries where several states action tables were 
almost identical.  So LALR1 generated table entries that said 
essentially: if the next token is X do Y, otherwise go to the state 
table for state Z.  You could distort the engine all out of shape to 
implement this, or put in a goto to just before the loop.

Someone who had been taught the "gotos are evil" religion reorganized 
the code with a couple of added state variables to demonstrate the goto 
wasn't necessary.  His code was only twenty lines longer than my code, 
and ran 40% slower. (Register pressure from those state variables push 
things that should have been in registers onto the stack.)  Although he 
talked about looking at the generated code to see why it was so much 
slower, I think he realized that his version was the spaghetti.

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney




  reply	other threads:[~2004-04-29  5:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-28 18:48 Hierarchical States Machines Fabien
2004-04-28 19:39 ` Marius Amado Alves
2004-04-28 19:57 ` Robert I. Eachus
2004-04-29  3:00   ` Randy Brukardt
2004-04-29  7:25     ` Martin Krischik
2004-04-29 20:37       ` Randy Brukardt
2004-04-29 12:10   ` Wojtek Narczynski
2004-04-29  3:58 ` Steve
2004-04-29  5:14   ` Robert I. Eachus [this message]
2004-04-29  6:36     ` tmoran
2004-04-29 16:36       ` Robert I. Eachus
2004-04-29 15:41   ` Marius Amado Alves
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox