Andy, Certainly the Singer 10 (which as a stripped IBM 360/148 Front end processor in its native form) when it was upgraded to the 220 by ICL did and it still maintained it's 10 bit architecture which made programming real fun! All the DRS 50 microcode was based on FSM architecture and this was lifted I believe from the 2903 which was ICL's first microcoded mini/mainframe. I can't vouch for the early 2900 ICL series as I never did any work on them to any degree.
The wierd thing is that when you are using a FSM system then it can't have any "properties" if it is to remain pure. A propery merely becomes an additional state but many times have I seen a "halfway house" solution where properties are used when dealing with software FSM's. One good thing about FSM is that it can only ever possess one state and that is the "current state" apart from when multi threading, but that adds a whole new bag of worms. The nice thing about the Singer 10 was that FSM handling was extremely rapid because of the 10 bit architecture and we could shift around data much quicker than the IMB equivalent machines ... and we were also completely solid state with genuine "core memory" so shutting off the machine mid run was not a problem. I do remember though, when the 220 came out, forgetting that it had volatile memory and going through my regular Singer 10 demo and turning off the power, much to the annoyance of my allocated salesman who went pale ... and lots of g uffawing and piss taking as I knew what I had done as soon as I pulled the switch! I remember the customer (the Co-Op) actually said that the cock up actually sold them the system as they realised that we were in fact human, unlike the IBM "slicko's" who had demonstrated their 360 some days before. Happy days indeed.. Anyway, on a lighter note, how are you doing with your living in, is it Goa lots of the time? Hope you are both well and enjoying the sunshine. Must admit it is a place I'd love to visit and it's on my bucket list! Dave -----Original Message----- From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of AndyHC Sent: 19 December 2013 11:21 To: profox@leafe.com Subject: Re: Finite State Machine Dave, did the IBM mainframe and early microprocessor model of instruction pointer; address / data registers map onto a finite-state machine? I can see how it might be done(e.g. by mapping op codes to microcoded OR/NAND/SHIFT/JUMP etc.), but I don't see why it /would/ be done that way. On 19/12/2013 15:39, Dave Crozier wrote: > A finite state machine/system is one that: > > a. knows the current status of the "machine" at all times b. can > recognise a state change of the machine c. reacts to a state change > via a predetermined set of rules d. triggers a change in state for any > state change in (c) above > > Although this would seem to be how any program/system can be defined, the > Finite State Machine (FSM) is very rigid in how it models the "system". You > need very structured code patterns and usually these are driven via an events > table where each event can have a number of states with events being rows and > states being columns. > > The table is scanned via the events handler and the combination of row/column > values at any instant in time dictate either a state change or a requirement > for a state change. This state change is then handled, normally in an > alternative programming thread and the results of the change fed back into > the events table. > > What happens is that the system becomes virtually dynamic with regards to > "consequential events" as there will be a finite but usually very large > number of "states" that have to be processed or recognised. > > Lots of the mainframe operating systems that I used to work on at Singer used > this methodology as did the early microcode mainframes at ICL. > > The biggest difficulty in writing software this way is not the programming, > it is actually defining the finite number of events, states and combinations > of the two that will generate a state change that may or may not affect the > actual state of the thread that is currently processing the change. > > Hope this makes sense as although it is a simple concept, the implementation > of it is not a trivial task. > > Dave > > > -----Original Message----- > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Nicholas > Geti > Sent: 19 December 2013 04:35 > To: profox@leafe.com > Subject: Finite State Machine > > Do any of you know the Finite State Machine technique for programming? Has > anyone used it to do programming? > > Nick Geti > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > --- StripMime Report -- processed MIME parts --- multipart/alternative > text/plain (text body -- kept) > text/html > --- > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/18725b8cd2d5d247873a2baf401d4ab22a477...@ex2010-a-fpl.fpl.LOCAL ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
