Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

finite state machines

Posted Mar 29, 2008 1:33 UTC (Sat) by man_ls (subscriber, #15091)
In reply to: an "old beard" ? by tialaramex
Parent article: Striking gold in binutils

Not that I know of. Finite state machines are actually hard to code and read in any language, so your argument (C++ somehow made gold more difficult) sounds like a red herring to me.

Oddly enough, it seems this is an area where graphical programming should help: state diagrams (or flowcharts) can really help you understand a state machine. But apart from some of the new BPM tooling, which covers a similar but different problem space, that idea hasn't flown either.

(Log in to post comments)

Posted Mar 29, 2008 7:30 UTC (Sat) by salimma (subscriber, #34460) [Link]

FSMs are trivial in languages with tail-call optimization (Lisp et. al., ML, Haskell .. even
Lua!). It is true, though, that most of these languages are not geared towards low-level bit
manipulation.

C--, perhaps. It's a C-like language used by the Haskell team as their intermediate language,
a sort of souped-up assembler.

finite state machines

Posted Mar 29, 2008 12:39 UTC (Sat) by man_ls (subscriber, #15091) [Link]

Oops, you are right: FSMs are indeed easier to implement in those languages. My big mouth again.

They are still pretty hard to follow and understand. Which is of course the concern of the author of gold. But maybe even this can be alleviated with functional programming; on the 7th Antual ICFP Programming Contest functional languages were shown to be an order of magnitude better at writing input for FSMs than imperative languages. I'm not so sure any longer.

So thanks for the clarification, and please disregard my earlier uninformed comment about a red herring.