This was a very powerfull concept back in 1975 and it influenced my hardware hacking for many years beyond 1975. A state machine consists of logic which impliments a finite number of states with transitions from state to state occurring as a result of specific input conditions synchronized with system clock transitions. A state machine is analagous to a software subroutine and it can be debugged in isolation just as a software subroutine can. State machines can perform autonomous operations, and higher level state machines can be utilized to coordinate the interactions of the lower level of state machines. This hierarchical structure can be extended as many levels as one requires.

The reason that I have included this as a separate topic is that divisions of any hardware project into appropriately sized chunks for efficient subunit debugging is a prerequisite for successful completion of the project. Most of the problems I've run into in my last 30+ years of hardware design and programming have been in attempting to do too much at once either in a particular logic circuit or program. Debugging of digital logic is a very unforgiving task. The number of potential errors increases as 2**(# of state machine flip-flops) and thus there is a very strong incentive to keep the number of states small. State machines that I utilized in 1976 had at most 16 distinct states, and even this limited number of states was sufficient to result in many long hours of debugging to track down subtle race conditions when one interfaced multiple state machines together.

I can't remember the title of the book now, but it was written by people who worked at Hewlett Packard and were involved in the design of early calculator chips in the 1970's. Their hierarchical state machine design concepts influenced both of my large scale electronics projects in 1975 and 1976; I just wish I could find a reference to the book to give these people that had such an influence on my early digital design period the acknowledgement that is due to them.

Once I had unlimited access to computers, I abandoned the lessons I had learned in my hardware hacking days as I dove into FORTRAN programming on the PDP-11 under RT11 from 1979 onwards. Programs from that era had a distressing habit of starting off as simple test programs, and then quickly evolved into nasty tangles of spagetti code the growth of which was only terminated when the RT-11 FORTRAN compiler refused to compile a program once it expanded beyond a certain size, or when I could no longer stay awake. I'm not sure why this stage in my programming career occurred; my previous programs had been appropriately segmented into subroutines, but the ability to directly interact with a computer on a teletype rather than a batch processed environment using punched cards seems to have facilitated this spagetti coding style. Also, I was under more time pressure to produce results and rather than testing separate subroutines I would incrementally and interactively expand programs which I eventually determined were limited by my ability to stay awake and keep various bits of the program in my head (around 48 usefull hours). I was seriously researching various ways of extending the usefullness of various pharmacologic methods to extend this limited programming window (I did work in the pharmacology department in UBC in 1979) when I came across the book: Software Tools by Kernighan and Plauger on 13/6/1981.

Reading Software Tools was one of the peak experiences in my life. I have my copy in front of me as I write this, and it doesn't seem like a big deal to me now, and actually appears somewhat quaint, but in 1981, the effect of this book was to totally reshape my programming style. I can't explain how I went from a hardware programming style (using the popular solder programming language), which was isomorphic with the approach Kernighan and Plauger discussed in their book, to spagetti coding which is so impenetrable that it is simpler for me to rewrite programs now rather than try to figure out what I was doing in 1980. (My laconic comment style of that era doesn't help much now; eg:
C Works! 5/4/1980 T:=04:01
would be the only comment in a program from that period in my life. C in "column 1" indicates a comment in FORTRAN.)

Software Tools was similar to the hierarchies of state machines concept in that it started off with simple bits of code which performed clearly defined operations and then through the combination of these simple programs, more and more complex operations could be performed by combination of these elemental programs. This book put me on the right track again as the inability to perform much usefull work after 48 hours awake was beginning to limit what I wanted to do.

The parsing of amorphous reality into appropriate meaningful chunks is a non-trivial process. (For an interesting consideration of this topic read Pirsig's book Zen and the Art of Motorcycle Maintenance). A non-programmer reading Software Tools would likely fall asleep from boredom; in my case it allowed me to rearrange my thought processes so that:
(1) I could write programs in a manner that sleep would not adversely affect, and
(2) I was again made aware of the division of a project into small, usefull chunks that can only be made less usefull when one elaborates on what they do.

Now, the process of parsing a project, whether it be hardware or software, into meaningfull chunks which can be easily implimented during a short work period dedicated to their creation, is so subconsious and automatic that I rarely think about it exept at times like these when I look into the past. This was a significant time, hence this page.