On 08/02/17 17:15, Phil Hobbs wrote:> On 02/06/2017 05:12 PM, Tom Gardner wrote: >> On 06/02/17 21:19, Don Y wrote: >>> On 2/6/2017 1:34 PM, Tom Gardner wrote: >>>> On 06/02/17 18:56, Don Y wrote: >>>>> On 2/6/2017 11:03 AM, Tom Gardner wrote: >>>>>>> I find that sometimes I'll sketch a FSM and then find out >>>>>>> it's just too simple or too linear. ON the flip side, I've had >>>>>>> project for >>>>>>> which >>>>>>> I'd have an extremely simple FSM documented and later it's starts >>>>>>> to get >>>>>>> elaborate and useful as new requirements emerge. >>>>>> >>>>>> Precisely. >>>>>> >>>>>> A large part of engineering is being able to >>>>>> demonstrate which part of an design implements >>>>>> each part of the specification. >>>>>> >>>>>> A good implementation of an FSM enables you >>>>>> to easily see exactly what will happen when >>>>>> any event occurs in any state. That can be very >>>>>> difficult with if-then-else clauses. >>>>> >>>>> Exactly. IME, they are excellent for representing UI actions >>>>> along with other formal "protocols". They allow you to verify >>>>> by inspection that all possibilities are addressed and >>>>> addressed in the manner intended -- without having to >>>>> count nesting levels of conditionals, etc. >>>>> "Will this 'if' cover this condition in ALL states? Or, >>>>> does it only apply to some subset of the states, based on >>>>> where it is syntactically anchored?" >>>>> >>>>> I'd *not* use one to implement a floating point package... >>>> >>>> Yes, but... >>>> >>>> They are very neat way of implementing parsing an ascii >>>> string and turning it into a floating point number. >>> >>> Different problem -- and one that could be "automated" with a >>> simple grammar/lex/yacc. >>> >>> You'd find it hard to apply it to performing multiplications, >>> divisions, etc. in a way that was anywhere near as efficient >>> as the underlying instruction set! >> >> Yes, and I didn't spot that "loonie idea" was being >> considered. >> >> >> >>> Allowing inputs to simultaneously arrive from multiple >>> sources WITHOUT enforcing an ordering on them external >>> to the FSM lets you cascade machines, have machines >>> talking to each other while operating concurrently, >>> implement co-routine machines, etc. >> >> Having architected and implemented soft-realtime >> telecom billing systems, I can only agree :) >> >> >>> It's just like designing synchronous hardware. >> >> Oh, indeed. >> >> I like playing a game with people that think >> there is a difference between hardware and >> software: get them to try to provide a test to >> distinguish one from the other. They always fail. >> >> It is best played in a pub, with a few pints, >> after work. >> >> > Discharge a big cap into it. If it still works, it's software. ;)Thus ruling out FPGAs :) Besides, if it is software, how could you be sure it worked before the discharge :)
Do you use FSMs or HSMs?
Started by ●February 6, 2017
Reply by ●February 8, 20172017-02-08
Reply by ●February 8, 20172017-02-08
On 02/08/2017 06:52 PM, Tom Gardner wrote: <sniiiiip>> Besides, if it is software, how could you > be sure it worked before the discharge :) >Curses, foiled again. ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●February 10, 20172017-02-10
George Neuner wrote:> On Mon, 6 Feb 2017 23:36:01 -0600, Les Cargill > <lcargill99@comcast.com> wrote: > >> Clifford Heath wrote: >> >>> Lex is a language for describing a regular expression, >>> which it implements by turning it *into* an FSA. >>> >>> You don't need yacc to parse FP numbers. Such parsers >>> are for handling languages that require unbounded state, >>> not finite state. >> >> Just to be pedantic :), it's deterministic vs. non deterministic FA. >> Deterministic FA are equivalent to regular expressions. NFA >> are not, and very often, NFA are what we use for program control flow. > > Every NFA is equivalent to some DFA, and either can be mechanically > translated into the other. However the DFA version, in general, will > have many more states: in the (theoretical) worst case, equal to the > size of the power set of states in the NFA. >I've had perfectly good NFA deployed that I would hate to have to translate into a regexp :) As a practical matter ( and as you note ) , there is a very significant tactical difference.> But such explosive growth is very rare. In practice, the majority of > elements in the power set of NFA states will represent either unwanted > or redundant operations. > > >>> I'm also enthusiastic in using FSAs where appropriate, >>> but a lot of problems I face require unbounded state. >> >> This is where NFA shine - they're less formal than DFA. > > Not "less formal" per se if you are concerned about correctness. > However, in general, NFA are easier to specify and to understand. >That's the key. As you say - there may be a (small) price in the ability to demonstrate correctness. The principal advantage is the ability to generate nearly exhaustive test suites for them. It at least becomes a matter of exploiting combinators.> Any particular state of the equivalent DFA may be simultaneously > representing multiple states of the NFA. Consequently, the > transition/acceptance rules in the DFA may be extremely complex - > perhaps even incomprehensible to mere mortals. > > > George >-- Les Cargill
Reply by ●February 10, 20172017-02-10
Paul Rubin wrote:> Les Cargill <lcargill99@comcast.com> writes: >> It's always dangerous to generalize, but anything I can easily >> make non-blocking I will. > > Ok, you prefer to handle the event dispatch manually, with callbacks or > a switch around the protocol state. I know some people find that > intuitive but I've never gotten the hang of it. >There are a small legion of approaches. It depends on the problem domain. But yeah - you dispatch event messages to a machine of some sort.>> Some FSM oriented systems use an "actor" model where actors can be >> threads or even pseudothreads[1], communicating with sequential >> message passing. > > Yes, that's what I'm used to doing under the covers. Each thread waits > for some action while appearing to block, and moves forward when the > action occurs. Erlang is designed for programming in this style and > some very complex, highly reliable systems (phone switches) have been > programmed in it. >Most/many of the protocols for circuit switched phone systems have explicit FSM drawn in the standards. It's possible to have "pseudothreads", where the event sink dispatches based on event type to whoever is waiting on that event. This does not require a separate, O/S thread each. You maintain the advantages of run-to-completion and in cases, can be done on something which is too small for an O/S. -- Les Cargill
Reply by ●February 10, 20172017-02-10
Les Cargill <lcargill99@comcast.com> writes:> It's possible to have "pseudothreads", where the event sink > dispatches based on event type to whoever is waiting on that event.Yes, this is what the Erlang runtime does under the hood. From the user program's perspective it looks like OS processes, but they are very lightweight--you can have many 1000s of them on a small computer, or millions on a big one.
Reply by ●February 11, 20172017-02-11
Paul Rubin wrote:> Les Cargill <lcargill99@comcast.com> writes: >> It's possible to have "pseudothreads", where the event sink >> dispatches based on event type to whoever is waiting on that event. > > Yes, this is what the Erlang runtime does under the hood. From the user > program's perspective it looks like OS processes, but they are very > lightweight--you can have many 1000s of them on a small computer, or > millions on a big one. >ObjecTime did the same, as did Rational Rose. -- Les Cargill
Reply by ●February 16, 20172017-02-16
In article <Xw6mA.154283$6N1.4638@fx09.am4>, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 06/02/17 21:19, Don Y wrote: >> It's just like designing synchronous hardware. > >Oh, indeed. > >I like playing a game with people that think >there is a difference between hardware and >software: get them to try to provide a test to >distinguish one from the other. They always fail. > >It is best played in a pub, with a few pints, >after work."I want to make these 15 changes. Can I have the changed model working tomorow and deployable next week?" OK, FPGAs have a fair shot at it, but most other hardware doesn't. Mind, the definition of "working" when it comes to software is quite notably different than it is for hardware. Nothing quite like a fresh tapeout because the verification team didn't get enough time. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices...
Reply by ●February 16, 20172017-02-16
On 17/02/17 00:30, Steve Watt wrote:> In article <Xw6mA.154283$6N1.4638@fx09.am4>, > Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >> On 06/02/17 21:19, Don Y wrote: >>> It's just like designing synchronous hardware. >> >> Oh, indeed. >> >> I like playing a game with people that think >> there is a difference between hardware and >> software: get them to try to provide a test to >> distinguish one from the other. They always fail. >> >> It is best played in a pub, with a few pints, >> after work. > > "I want to make these 15 changes. Can I have the changed model working > tomorow and deployable next week?"Sometimes software can become ossified; typical unit-testing practices (in XP/TDD/agile methods) actively encourage that. I've seen a company where the software turnaround time was 6 *months*, due to software that had grown like a cancerous tumour, and inept internal structure.> OK, FPGAs have a fair shot at it, but most other hardware doesn't.It largely depends on how many are required. One-off is more likely to be do-able in hardware.> Mind, the definition of "working" when it comes to software is quite > notably different than it is for hardware. Nothing quite like > a fresh tapeout because the verification team didn't get enough time.Ditto much hardware. Summary: insufficient differences to be a useful test.
