Innovation in the computer industry — Personal recollections (part 2)
Recently, I published the first episode of my experiences in the computer industry: Innovation in the computer industry — Personal recollections (part 1). In this post, I described how I became interested and initially trained in computer hardware and software, as well as experiences from my first job in the industry.
While my experiences at ARCO were extremely interesting and what I learned was valuable, it certainly wasn’t the front row seat to the participation and observations of some of the most innovation advances to come. That would happen when I joined Digital Equipment Corporation. But first, I needed to find my niche in the industry which ended up in operating system (OS) development.
Cold War Development
In late 1981, I went to work for Sanders Associates in Nashua, NH. Sanders was a defense contractor, that in 1986 was bought by Lockheed, which after some more mergers/acquisitions was absorbed by BAE Systems. At Sanders, I was extremely fortunate to work on two projects, the update program to the S3B carrier-lauched submarine hunting jet and the air traffic control system for Tempelhof airport in West Berlin.
Note: Though some of my work was classified, what I’m describing below was not classified.
For anyone who has been a fan of Tom Clancy’s books or movies, you’ve most likely read or seen The Hunt for Red October. This early Jack Ryan book was about the tracking and attempted contact and/or sinking of an advanced Soviet submarine, the Red October.
In that movie, one of the non-human stars of the film was the sonar system on the US sub, the USS Dallas. Also, there was a scene of a P3 Orion airplane dropping a torpedo into the water in an attempt to sink the sub. Sonar was the only method to find, track and provide targeting information to kill subs.
The P3 aircraft is a prop plane that takes off and lands from an airfield. It looks for, tracks and possibly engages subs. The carrier launched alternative is a small jet, with large turbines called an S3 Viking. It looks a lot like a Fisher-Price plane. 🙂 Like the P3, the Viking primarily was a sub hunter and could be armed with torpedoes and other armaments. In the early ’80s, I worked on the upgrade project, called S3B. Specifically, I worked the development of the operating system to be used on a pair of computers driving large, bit-mapped display screens. These screens were used to provide visual representation of underwater sounds picked up by sonobuoys that the plane dropped once on station.
Since the display computers were between the computer that captured the sound and digitized the sound and another computer that performed some sophisticated pattern matching against the data stream, our little computers also needed to provide fairly complicated real-time data switching and passthrough.
For me, this was my first opportunity to work in the world of operating systems. We needed to develop an OS that would be real-time, robust, provide sophisticated job and data management and along with the applications, fit into 64 KB of memory. We were to develop the OS for a Navy computer (AN/AYK-14), using a Navy high-level language (CMS-2). Unfortunately, the latter requirement needed to change due to a shortcoming of the computer architecture: The computer (and hence the language) didn’t natively support stacks.
What is a stack? It’s known as a FILO data structure, where the first data in will become the last off. Years ago, I was at a diner where the plates were in a hole in the counter. As plates were added, a spring would ease allowing the top plate to remain even with the counter. As plates were pulled off, the plate “stack” would rise. This is the way a data stack works, data gets pushed on, then to get to the data, the data on top needs to be pulled of in reverse order that it was pushed.
Stacks are crucial to OS design because, they are the only high performance way to store data when context switching, which is used when temporarily stopping one job to run another.
To solve the problem, we needed to develop routines to implement stacks, which could only be done in assembly language, which is a low-level language where each instruction corresponds to a single machine instruction. Also, to get around the lack of a stack, CMS-2 used self-modifying code, that would insert the return address into the end of a sub-routine that would be executed when the code hit that instruction. Again, this did not permit the level of sophistication we required.
The overall project was one of the most fun and challenging I’ve worked on and it provided me with fundamental skills that I would end up using going forward both at Sanders and in the commercial space.
Air Traffic Control
The other project that I worked on was a new air traffic control (ATC) radar system for Templehof Airport in West Berlin. The purpose of this system was to control the air corridors from West Germany through East Germany to West Berlin. As you may remember, West Berlin was deep inside East Germany.
The role of my team was to take an early version of UNIX, version 6 and modify it to run in real-time. It was to run on 16 bit minicomputers that controlled and coordinated the various radar stations. UNIX was chosen due to its fairly generous licensing provisions, particularly the freedom to modify the code base. In many ways, it presaged the Open Source movement. AT&T developed the original UNIX at Bell Labs in NJ. The problem we needed to resolve was to make it operate in real-time.
What does real-time mean? Operating systems like Windows, MacOS or Linux (or UNIX for that matter) do not function in real-time. If you pop up a window and one time it takes 1/2 second and other time 2 seconds, you probably don’t notice. It certainly doesn’t adversely affect the operation. Computers in real-time need to be predicable. If it takes 1/2 second to perform an action, it needs to take 1/2 second each and every time. Also, if you have say 3 apps running, there are typically interchanges between them that require that they be sequenced properly. This required a real-time scheduler.
For this project, we needed to add real-time scheduling, where real-time processes would get priority and be scheduled in a very deterministic manner (meaning, they will run when expected). However, for this to be effective, we needed to comb through the entire OS looking for places where things were not deterministic enough.
One example: We had a real-time task that displayed data on a terminal. Most of the time, it took 30 msecs (30 thousands of a second) to display the data, but periodically it would take 3 seconds. We needed to painstakingly trace and monitor all the paths taken looking for what was slowing it down. After several days work, we found an interrupt that would occur that would wait for some other action for about 2.5 secs. An interrupt is some block of code that “interrupts” the current running job do perform some high priority task, then returns control to the job when complete (hence the need for a stack). Typically interrupts are very fast so as not to adversely effect performance. One example is a clock that interrupts execution to check if something else needs to be scheduled. It doesn’t necessarily do the task, it just sets a reminder then returns to the executing job.
So, a 2.5 second delay meant the interrupt wasn’t working properly, since it was waiting for something to happen before it completed. We tracked that down to a broken communication path that when fixed, resolved the delay and hence the problem. Again, for a normal OS, you wouldn’t notice, but in the world of real-time, its crucial.
My experiences at Sanders provided the fundamental grounding in OS design and implementation that led me to the middle of development of new machines and the modification of UNIX to support the ever increasing complexity and sophistication leading up to today’s systems.
Next: a front row seat to The Innovators …