Finites State Machine (OT?)

[R. Steve Walz]

Rich Grise wrote:

"R. Steve Walz" <rstevew@armory.com> wrote in message
news:40A5B82D.3BEA@armory.com...
del cecchi wrote:

Thanks for letting me know that one can implement state machines in
microcode. It had never occurred to me.
-------------
Why do we believe you?

Because why would he lie?

Cheers!
Rich
-----------------

Look, Rich, if you don't even GET the humor, don't try to re-tell
the joke, it embarrases us for you.

Joke explained (WHY do I bother?):
Since he knew and pretended he hadn't, saying "Why do we believe
you" is an amusing backhanded cut.

Then you trying to stick up for his honesty shows your ignorance,
because he was intentionally lying to be smug. Your notion that
*I* actually thought that he didn't know was simply your error
in the level of subtletly you perceieved in the convertsation.

-Steve
--
-Steve Walz rstevew@armory.com ftp://ftp.armory.com/pub/user/rstevew
Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
http://www.armory.com/~rstevew or http://www.armory.com/~rstevew/Public

 

[Sander Vesik]

In comp.arch R. Steve Walz <rstevew@armory.com> wrote:

Sander Vesik wrote:

In comp.arch R. Steve Walz <rstevew@armory.com> wrote:
Del Cecchi wrote:

"pdx" <pdx@spamtrap.com> wrote in message
news:2ghvjqF3429bU1@uni-berlin.de...
Sorry if this is off topic but I have another question to help with the
revision for my exam (it's tomorrow).

Why would a finite state machine be an appropriate method of implementing
the control logic of a drinks vending machine?


Another trick question. These days it isn't an appropriate way. The
appropriate way is with an embedded microprocessor. Finite state machines
only made sense when microprocessors were too expensive.
------------
You're not grasping that state machines are also implemented with
microprocessors these days, it's not either-or.

You should read up on Del's posting history. He grasps a rather disconcerningly
-----------------
And so you're his doting fellatrix?

No.

large amount of very complex things.
-------------------
So may he. So do I.
But which may still exclude the truth I mentioned on his part.

You see:
I don't HAVE to know everything to be smarter than YOU are.
Grasp set theory, over and against statistics you can't know.

Its not apparent you grasp much relevant to the group i'm reading
this from.

-Steve

--
Sander

+++ Out of cheese error +++

 

[R. Steve Walz]

Sander Vesik wrote:

In comp.arch R. Steve Walz <rstevew@armory.com> wrote:
Sander Vesik wrote:

In comp.arch R. Steve Walz <rstevew@armory.com> wrote:
Del Cecchi wrote:

"pdx" <pdx@spamtrap.com> wrote in message
news:2ghvjqF3429bU1@uni-berlin.de...
Sorry if this is off topic but I have another question to help with the
revision for my exam (it's tomorrow).

Why would a finite state machine be an appropriate method of implementing
the control logic of a drinks vending machine?


Another trick question. These days it isn't an appropriate way. The
appropriate way is with an embedded microprocessor. Finite state machines
only made sense when microprocessors were too expensive.
------------
You're not grasping that state machines are also implemented with
microprocessors these days, it's not either-or.

You should read up on Del's posting history. He grasps a rather disconcerningly
-----------------
And so you're his doting fellatrix?


No.


large amount of very complex things.
-------------------
So may he. So do I.
But which may still exclude the truth I mentioned on his part.

You see:
I don't HAVE to know everything to be smarter than YOU are.
Grasp set theory, over and against statistics you can't know.


Its not apparent you grasp much relevant to the group i'm reading
this from.
-------------------------

You'd be quite wrong.

Sander
+++ Out of cheese error +++
-----------------------

Try Wensleydale!

-Steve
--
-Steve Walz rstevew@armory.com ftp://ftp.armory.com/pub/user/rstevew
Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
http://www.armory.com/~rstevew or http://www.armory.com/~rstevew/Public

 

[Stephen Sprunk]

"Rich Grise" <null@example.net> wrote in message
news:Rixpc.203135$L31.81417@nwrddc01.gnilink.net...

"Stephen Sprunk" <stephen@sprunk.org> wrote in message
news:54c913784ee956f775751183d92ce20d@news.teranews.com...
"Active8" <reply2group@ndbbm.net> wrote in message
I'd like to see an example of how an IRC server is implemented with
a FSM. I can't quite draw a mental picture. I don't know the IRC
protocol, either.

When a client first connects to a server, there are all sorts of things
the server must do before it allows the client to start chatting, such
as
checking DNS, IDENT, and an optional username/password. Since
the standard ways to check these things are blocking and the server
only has one thread, an FSM is very useful. Here's a pseudocode
example:

Pardon me, but what server do you have that has only one thread?

There's only one common implementation, ircd. The variant I've used is the
one for EFnet, but AFAIK all public networks use trivial patches to the same
common base.

And any given thing can block its particular system call, yes, but
your main loop dispatches the functions and rather than waiting for
a particular link in the chain, it can go ahead and do something
else, and just check back whenever it wants to try thing 1 again.

That's true for simpler operations like read() and write(), but others such
as gethostbyaddr() are pretty much guaranteed to block under any conditions
and no non-blocking versions are available. Even if everything were
non-blocking, you'd still need an FSM to be able to pick up where you left
off on the next pass through all the connections.

Or are you saying that a FSM is indistinguishable from a flowchart?

I've never seen an FSM that remotely looked like a flowchart.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

 

[Terry Given]

"Jeffrey C. Dege" <jdege@jdege.visi.com> wrote in message
news:slrncad8aa.an5.jdege@jdege.visi.com...

On Sat, 15 May 2004 20:29:38 GMT, Stephen Sprunk <stephen@sprunk.org
wrote:
"Terry Given" <the_domes@xtra.co.nz> wrote in message
news:asopc.5574$XI4.198306@news.xtra.co.nz...
"Jeffrey C. Dege" <jdege@jdege.visi.com> wrote in message
news:slrncac317.2ta.jdege@jdege.visi.com...
I once tried to debug a program that consisted of a single 3500-line
while loop that _would_ have been a state machine, if the programmer
had known what a state machine was.

sounds terrible. I bet you couldnt convince the programmer that it was
a
state machine, and therefore can be analysed as such.....

First you'd have to teach the original coder what a state machine is...
It
certainly wasn't covered in the Comp Sci classes I took or in any of the
dozen books I've read on programming since then; I finally learned about
FSMs when trying to decipher some RFCs on routing protocols, and I still
don't think of them at first when approaching a problem.

I don't see how you could possibly teach a compiler class without
either covering, or requiring as prerequisite, finite automata and
state machines.

I do - in an attempt to boost student numbers, and hence government funding.
If that is the objective, then producing useful, skilled grads is NOT, so
who cares if they dont know about FA/FSM? Besides, arent compilers written
with compiler compilers nowadays.....

I learned about FSM as a 14-year-old kid, I had a friend who worked for NCR,
and him, me and my mate bruce networked our ataris thru the joystick port;
he was a failed comp sci student, and taught me and bruce much about program
design.

I also "learned" them at uni, although they were covered only briefly in
comp sci. Digital electronics papers covered them in detail, as expected (As
a kid, I tried repeatedly to design a DRAM controller for 4116's (pinched
from a dead defender pcb, using 3 supplies - +5V, -5V, +12V IIRC) but
couldnt, as I didnt understand FSM. I got David Comer's appropriately titled
book, and off I went. Eventually, my DRAM controller actually worked, but it
took me about 3 years to make it so)

And I don't see how a degree in Comp Sci could not include classes in
compiler technology and context-free grammars.

comp sci students are cheap - all you need is a lecture theatre (uni's have
these) and a computer room (they have these too) and you can pump out
thousands of fee-paying "grads" every year.....there is a plague of these
people, and it probably goes some way to explaining the fact that modern
software is generally unreliable, bug-riddled shite.

Terry

 

[John S. Dyson]

In article <dDBpc.5787$XI4.206587@news.xtra.co.nz>,
"Terry Given" <the_domes@xtra.co.nz> writes:

comp sci students are cheap - all you need is a lecture theatre (uni's have
these) and a computer room (they have these too) and you can pump out
thousands of fee-paying "grads" every year.....there is a plague of these
people, and it probably goes some way to explaining the fact that modern
software is generally unreliable, bug-riddled shite.

Good and complex software often requires a significant emotional/intellectual

investment from the developers, and cookie cutter implementation of new
or non-trivial software is unrealistic. Creating cookie cutter software
developers who don't invest much of their selves into their work will
result in alot of sloppy, suboptimal, buggy, or less than desirable
quality software.

Non-trivial software does often require 'thinking', and that requires
investment from the 'thinker'. Spending 'time' on a project isn't
sufficient (or sometimes even necessary.) The old idea of 'working
smart, not hard' isn't 100% true, because 'working smart' can require
alot of effort -- but with the payoff of minimizing more brute force
work in the future.

Maybe one of the more important attributes would be that the programmer
enjoy the work, and be willing to intensely invest in the early phases
so as to mitigate needed brute force development and inefficient test/debug
cycles later on.

Development teams also have made the mistake of replacing careful
implementation and design with brute force 'test/debug' cycles. This
is even worse than violating the 'work smart, not hard*' rule. (Again,
the implication of working 'hard' is relative.) For quick programming
hack projects, the 'test/debug' cycle has been re-enforced by using
incredibly fast computers nowadays, but even in the trivial case, a
careful design can save lots of time.

John

 

[Rich Grise]

"Terry Given" <the_domes@xtra.co.nz> wrote in message
news:dDBpc.5787$XI4.206587@news.xtra.co.nz...

I learned about FSM as a 14-year-old kid, I had a friend who worked for
NCR,
and him, me and my mate bruce networked our ataris thru the joystick port;
he was a failed comp sci student, and taught me and bruce much about
program
design.

So, you're saying you learned about computers/state machines from a guy who
flunked?

Cheers!
Rich

 

[Peter Boyle]

On Sun, 16 May 2004, John S. Dyson wrote:

Non-trivial software does often require 'thinking', and that requires
investment from the 'thinker'. Spending 'time' on a project isn't
sufficient (or sometimes even necessary.) The old idea of 'working
smart, not hard' isn't 100% true, because 'working smart' can require
alot of effort -- but with the payoff of minimizing more brute force
work in the future.

better yet "work smart _AND_ hard" (quality people in small quantities).

Peter Boyle

 

[Active8]

On Sat, 15 May 2004 17:04:54 GMT, Stephen Sprunk wrote:

"Active8" <reply2group@ndbbm.net> wrote in message
news:5vmxhvmz3fu3.dlg@news.individual.net...
On Sat, 15 May 2004 05:25:09 GMT, Stephen Sprunk wrote:
FSMs are almost indispensible when writing software that needs to handle
multiple client connections per server thread. IRC servers, for
instance,
handle tens of thousands of connections with a single server thread via
an
FSM, whereas common HTTP server implementations require dozens of server
threads yet still grind to a halt when the number of active clients
exceeds
the size of the thread pool.

I'd like to see an example of how an IRC server is implemented with
a FSM. I can't quite draw a mental picture. I don't know the IRC
protocol, either.

When a client first connects to a server, there are all sorts of things the
server must do before it allows the client to start chatting, such as
checking DNS, IDENT, and an optional username/password. Since the standard
ways to check these things are blocking and the server only has one thread,
an FSM is very useful. Here's a pseudocode example:

IDLE:
client connects
send DNS request
start timer
move to DNS_WAIT

DNS_WAIT:
if timer expires, move to DNS_ERROR, otherwise:
update client_info with DNS response
send IDENT request
start timer
move to IDENT_WAIT

IDENT_WAIT:
if timer expires, move to IDENT_ERROR, otherwise:
update client_info with IDENT response
if anonymous users allowed, move to USER_CONNECTED
else start timer and move to USER_WAIT

USER_WAIT:
if timer expires, move to USER_ERROR, otherwise:
update client_info with username
start timer
move to PASS_WAIT

PASS_WAIT:
if timer expires, move to USER_ERROR, otherwise:
if password correct, move to USER_CONNECTED
else restart timer and move to USER_WAIT

USER_CONNECTED:
if timer expires, move to INACTIVE_ERROR
if input rate exceeds threshhold, move to USER_FLOOD
if username received, update client_info, start timer, and move to PASS_WAIT
if OPER command received and valid, move to OPER_CONNECTED
parse one user-level command in input buffer
restart timer

USER_FLOOD
if input rate below threshold, move to USER_CONNECTED
else discard any input

OPER_CONNECTED
if MODE -o command received, restart timer and move to USER_CONNECTED
(operator returning to user status)
parse multiple user- or operator-level commands in input buffer

Obviously there are a number of error states referenced which I didn't give
pseudocode for, but they either terminate the connection (and move to IDLE)
or kick back an error and move to another state depending on the admin's
configuration.

S

Thanks. I see now. I forgot that I started a little chat program -
actually IM. In it's present state, you have to know the IP addy of
the recipient and the recipient gets the IP addy from the sender via
some method of the ActiveX control I used which should tell you that
my app is probably a microshaft dependant POS I was just toying
with an idea - starting with the basic crap and building from there
- IMing my girlfriend without having to worry about the whole world
knowing what we were going to be doing later

Maybe one day I'll check out some open source code. Nah... I'd
rather check her out
--
Best Regards,
Mike

 

[Terry Given]

"Rich Grise" <null@example.net> wrote in message
news:uMDpc.130495$G_.21322@nwrddc02.gnilink.net...

"Terry Given" <the_domes@xtra.co.nz> wrote in message
news:dDBpc.5787$XI4.206587@news.xtra.co.nz...

I learned about FSM as a 14-year-old kid, I had a friend who worked for
NCR,
and him, me and my mate bruce networked our ataris thru the joystick
port;
he was a failed comp sci student, and taught me and bruce much about
program
design.

So, you're saying you learned about computers/state machines from a guy
who
flunked?

Cheers!
Rich

Why yes, I did indeed (at the ripe old age of 14). He flunked because (his
explanation) he was too busy writing software to bother with uni. He called
them ASMs though. But the networking software worked, and bruce and I
certainly upskilled a lot.

I have worked with a number of uni grads - BE, ME, PhD - and have found the
degree is not a valid predictor of ability. Ultimately, a degree proves
conclusively that you met the minimum standards required to get it, and
proves bugger all else. Most of the dreadful design problems I have posted
to s.e.d. have been the result of 2 people, one ME (MIT) the other PhD
(MIT), neither of whom deserve the title engineer.

Conversely I have worked with a number of technicians, some without any
formal training whatsoever, who have been highly skilled (about half of them
have since obtained BE's and become very good design engineers). In general,
those with degrees tend to have better mathematical skills than those
without. This is not necessarily important though, as maths alone rarely
leads to novel solutions - inspiration/perspiration usually does that.

It is, however, very frustrating arguing with people with limited technical
education, when the problem is their lack of understanding of complex issues
(usually mathematical). Try explaining pole placement to an electrician (pcb
layout guy), who insists that "220pF is too small" (in this case it was a
flyback compensation network re-design, to raise Fcross from 0.5Hz (yes,
0.5Hz - a moving coil meter would clearly show the transient response) to
abound 1kHz. I "won" the argument by pulling rank, and promising to endure
public humiliation if I was wrong).

The degree is most useful when it comes to getting your first job (those
without degrees tend to get filed in the "round" file). After that,
employment history tends to dominate. Although I have had a lot of success
in job interviews (one in particular) with pointing out design improvements
which can save money/improve reliability.

 

[Jeffrey C. Dege]

On Sun, 16 May 2004 20:31:33 -0700, Terry Given <the_domes@xtra.co.nz> wrote:

It is, however, very frustrating arguing with people with limited technical
education, when the problem is their lack of understanding of complex issues
(usually mathematical).

My particular beef is with people who invent their own "solutions"
to problems for which there are long-proven solutions.

--
"The national budget must be balanced. The public debt must be
reduced; the arrogance of the authorities must be moderated and
controlled. Payments to foreign governments must be reduced,
if the nation doesn't want to go bankrupt. People must again
learn to work, instead of living on public assistance."
- Marcus Tullius Cicero

 

[John S. Dyson]

In article <slrncaf0uo.qal.jdege@jdege.visi.com>,
jdege@jdege.visi.com (Jeffrey C. Dege) writes:

On Sun, 16 May 2004 20:31:33 -0700, Terry Given <the_domes@xtra.co.nz> wrote:

It is, however, very frustrating arguing with people with limited technical
education, when the problem is their lack of understanding of complex issues
(usually mathematical).

My particular beef is with people who invent their own "solutions"
to problems for which there are long-proven solutions.

Some invention can be useful -- but I agree that too often a 'new engineer'

will reinvent techniques that have been long ago originated. The few
times that I have 'really' innovated, I had to do long patent searches
to make sure that I didnt' stomp on someone else (making sure that my
design wouldn't cause problems.) FreeBSD has one of those semi-innovations,
where I had to do alot of research to make sure that there wasn't
a problem. (If being done for a large company, I would have probably
had to patent the design.)

John

 

[John Larkin]

On 16 May 2004 15:08:08 GMT, jdege@jdege.visi.com (Jeffrey C. Dege)
wrote:

My particular beef is with people who invent their own "solutions"
to problems for which there are long-proven solutions.

But new circuits are fun! I try to never copy anybody's old designs,
including my own.

John

 

[Sir Charles W. Shults III]

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message news:l6afa0tjs4mr8u9rc2n39dq7au2k2shema@4ax.com...

On 16 May 2004 15:08:08 GMT, jdege@jdege.visi.com (Jeffrey C. Dege)
wrote:

My particular beef is with people who invent their own "solutions"
to problems for which there are long-proven solutions.

But new circuits are fun! I try to never copy anybody's old designs,
including my own.

Exactly! And you are far less likely to run into copyright or patent
problems that way.

 

[John S. Dyson]

In article <NQNpc.34092$2f6.1210224@twister.tampabay.rr.com>,
"Sir Charles W. Shults III" <NOaichipSPAM@cfl.rr.com> writes:

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message news:l6afa0tjs4mr8u9rc2n39dq7au2k2shema@4ax.com...
On 16 May 2004 15:08:08 GMT, jdege@jdege.visi.com (Jeffrey C. Dege)
wrote:

My particular beef is with people who invent their own "solutions"
to problems for which there are long-proven solutions.

But new circuits are fun! I try to never copy anybody's old designs,
including my own.


Exactly! And you are far less likely to run into copyright or patent
problems that way.

All too often an 'invention' is a 're-invention' and too often

conflicting with previous patents. Of course, trying to clean
room a design does help with copyright. (Ignorance of a
patent shouldn't give amnesty for a violation... Well, there
are too many 'obvious' patents, but ignore that.)

John

 

[john jakson]

"R. Steve Walz" <rstevew@armory.com> wrote in message > > > -Steve

You realize that you have made a complete fool of yourself.
------------------------
That's merely your disingenuous lie.


Relax and read a few old c.a posts before insulting the prefects
------------------------
I AM among the prefects, you insipid little shit-mind!

(here since 1992)

-Steve

No Steve, you a big fat TURD, go flush yourself!

 

[Stephen Sprunk]

"john jakson" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0405161310.5d451fb7@posting.google.com...

"R. Steve Walz" <rstevew@armory.com> wrote in message > > > -Steve
You realize that you have made a complete fool of yourself.
------------------------
That's merely your disingenuous lie.

Relax and read a few old c.a posts before insulting the prefects
------------------------
I AM among the prefects, you insipid little shit-mind!

No Steve, you a big fat TURD, go flush yourself!

Boys, can you please at least _pretend_ to be professionals before we're all
forced to killfile you?

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

 

[R. Steve Walz]

john jakson wrote:

"R. Steve Walz" <rstevew@armory.com> wrote in message > > > -Steve

You realize that you have made a complete fool of yourself.
------------------------
That's merely your disingenuous lie.


Relax and read a few old c.a posts before insulting the prefects
------------------------
I AM among the prefects, you insipid little shit-mind!

(here since 1992)

-Steve

No Steve, you a big fat TURD, go flush yourself!
---------------

You're ignorant, illiterate, and insubstantial.

-Steve
--
-Steve Walz rstevew@armory.com ftp://ftp.armory.com/pub/user/rstevew
Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
http://www.armory.com/~rstevew or http://www.armory.com/~rstevew/Public

 

[Toon Moene]

Terje Mathisen wrote:

Jeffrey C. Dege wrote:

I once tried to debug a program that consisted of a single 3500-line
while loop that _would_ have been a state machine, if the programmer
had known what a state machine was.

Hmmm... Wy do I get the feeling that 'tried' is the operative word here?
:-(

"Real Programmers are not afraid of five-page-long do loops ..."

Hmmm, 3500 / 60 ~ 60

OK, I see your point.

--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

 

[Rich Grise]

"Toon Moene" <toon@moene.indiv.nluug.nl> wrote in message
news:40a933f1$0$4927$4d4ebb8e@news.nl.uu.net...

Terje Mathisen wrote:

Jeffrey C. Dege wrote:

I once tried to debug a program that consisted of a single 3500-line
while loop that _would_ have been a state machine, if the programmer
had known what a state machine was.

Hmmm... Wy do I get the feeling that 'tried' is the operative word here?
:-(

"Real Programmers are not afraid of five-page-long do loops ..."

Maybe not, but it sounds more like bravado to me. An _effective_
programmer keeps both ends of his loops on the same page.

Cheers!
Rich