|[10 earlier articles]|
|Re: Loop Optimizations and Gotos email@example.com (1995-11-21)|
|Re: Loop Optimizations and Gotos firstname.lastname@example.org (1995-11-21)|
|Re: Loop Optimizations and Gotos email@example.com (1995-11-22)|
|Re: Loop Optimizations and Gotos Paul_Long@ortel.org (1995-11-23)|
|Re: Loop Optimizations and Gotos firstname.lastname@example.org (1995-11-27)|
|Re: Loop Optimizations and Gotos email@example.com (Dave Lloyd) (1995-11-27)|
|Re: Loop Optimizations and Gotos firstname.lastname@example.org (1995-11-29)|
|From:||email@example.com (Herman Rubin)|
|Organization:||Purdue University Statistics Department|
|References:||95-11-076 95-11-107 95-11-158 95-11-179|
|Date:||Wed, 29 Nov 1995 19:31:34 GMT|
firstname.lastname@example.org (Herman Rubin) wrote:
>How can one avoid many unnecessary steps when there are numerous
>logical exits from a block? One case of this is entrance to a
Paul Long <email@example.com> wrote:
>See the paper, "How (Not) to Code a Finite State Machine,"
>Douglas W. Jones, _SIGPLAN Notices_, vol. 23, no. 8, August
>1988, for another alternative to implementing FSMs that you
>may not have thought about that avoids the problems you
I have read this paper, and the method used will not work on
state machines of fairly low complexity, but higher than the
example in that paper. The method advocated is, in the example
given, exactly equivalent to a goto method which is also given.
Since it is exactly equivalent, and the goto method is more
versatile, I claim that this gives gotos the edge. It does
agree with my position that the state should normally be
contained only in the location in code.
It also does not handle the case of multiple entrance optimally;
I cannot see how this can be done except by entering the state
machine with a goto, if the state is only to be kept in the location.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
firstname.lastname@example.org Phone: (317)494-6054 FAX: (317)494-0558
Return to the
Search the comp.compilers archives again.