Transition Machine Papers
By the late seventies and early eighties I had had ample opportunity to program many of the early computers. By then relays and vacuum tubes were already things of the past; these computers were built using transistors, then integrated circuits, LSI, and VLSI. They had small donut core memories and peripheral magnetic storage devices of disks, tape reels and cassettes, floppies, etc. They had unique machine and assembly languages and mechanisms for getting programs into the device. Using Marchant calculators to validate computations, I programed a range of on-board computers with core memories, to the full room DDP, DEC, IBM, and Sperry Rand UNIVAC computers with huge oil drum size drum memory devices. Access mechanisms included fingering binary instructions through switch indicators on a front panel, having a key punch operator punch cards from hand-written sheets, handing the card decks to a designated human computer operator, or loading them into a card reader oneself if one had access to the computer, using paper tape, mylar tape, magnetic tape, teletype, and later, typewriters. Languages I had used to write programs ranged from a Digital Differential Analyser (DDA) for implementing ‘strap-down’ attitude reference algorithms for the Lunar Rover, the seven instruction set of the onboard DELCO computer machine language with 1536 16-bit words of memory to guide a nuclear missile using fixed point arithmetic, to using the micro programs that manipulated control pulses that implemented the machine language instruction set of the computer that would ultimately be onboard the manned landing on the moon, to higher level languages including Basic, Fortran, C, Simscript, Sleuth, Algol, and Ada.
Skilled programmers became adept at writing the smallest and fastest possible programs, sometimes totally obscuring the purpose of a program to save an extra word of the rare resource of memory or defining data so as to avoid a multiply instruction that required 150 milliseconds to execute and especially divides that took 240. Always speaking to computers in their own language alienated programmers from their bosses, families, and friends. Computers had to be ‘commanded’ – pretty much against their will, or so it seemed. These were all aspects of programming computers with the Von Neumann architecture requiring explicit control constructs such as GO TO, DO, IF… THEN… ELSE…, CALL, etc. These are not statements we make to capable people if we like them. We say things like, “Your input is ready,” or we just prepare it without the overhead of comment. One doesn’t add, “Now you must go and do your job,” unless one is joking or a jerk. No. Managers who overmanage either have inept employees or are just bad managers. An ideal employee does his job which involves performing some task for which he is trained. When he is done he places it where it is available for whoever needs that to do their task. I thought computers should be ideal employees. So by the late seventies I had conceived a passive control concept based on that principle: When the conditions required to perform a task had been realized, an available processor accepted it. And yes, why only one computer? Any available computer with the capability can do it. Upon completing the task conditions implied by its having been completed were updated. That’s all there is to it. One of the papers was selected for the Outstanding Paper Award of 1979; two others were nominated as Best Paper at IEEE and or ACM conferences. In addition to the papers included here, there were three method patents issued for this research that were granted in 51 countries:
Pat. # 4,319,321, March 9, 1982: Transition Machine — A General Purpose Computer. 52 Claims
Pat. # 4,328,542, May 4, 1982: Secure implementation of Transition Machine Computer. 46 Claims
Pat. # 4,379,326, April 5, 1983: Modular System Controller for a Transition Machine. 47 Claims
A final paper concerning the benefits of software development employing the architectural features of the transition machine was accepted and published while I was on ‘sabbatical’ from the Boeing Company. I have found that paper and include it here; it primarily addressed fault tolerant computing using transition machines. After returning to the company, an outgrowth of the concept that programs should be written in human language was employed on two major Boeing Aerospace projects. The language structure now denominated ‘Behavior Specs’ was used to implement the software on the Boeing 777 commercial airliner cabin management system with up to 1500 computers throughout the cabin using a small interpreter in each computer that acted as a system controller of translatable specifications to be executed. This approach was then transferred to the B-1 bomber avionics upgrade project. Requisite conditions on databases have names — English names if you will, like “personnel data have been updated”. The tasks perform meaningful jobs from an English language perspective; they are described by nouns, verbs, and adjectives. English descriptions like “compute the average” “ages” of “nursing” “personnel” fall into one or another of these designated parts of speech. Then programs can be written as sentences: “WHEN personnel data have been updated, compute the average of the ages of nursing personnel. THEN set the average age of nursing personnel as available.” It’s not rocket science. In this form, everyone involved in the software development activity from requirements specification, testing, and product acceptance can have equal visibility of details of the project. It should be noted that Kellerman’s original specification of ‘transition systems’ was as an artificial language amenable to mathematical proofs of correctness. But as he described it, the actual program had to be re-phrased from the actual program to obtain proof of correctness. Transition machine concepts eliminated the difficult and error prone task of rephrasing a program fraught with control structures.
Outstanding Paper Award Notification
Microprocessor Based Transition Machines
A Prototype Parallel Computer Architecture for Advanced Avionics Application
Eight-processor prototype research model photograph
Direct Architectural Implementation of a Requirements Oriented Programming Structure
Software Development System for Transition Machines
Limiting Multiprocessor Performance Analysis
A Broad Range of Programmable Fault Tolerance in Transition Machine Computer Architecture
An Analysis of Multiprocessor Throughput Performance in the Limit