by Conrad Weisert, November 3, 2015
ŠInformation Disciplines, Inc.
NOTE: This document may be circulated or quoted from freely,
as long as the copyright credit is included.
In 1959 the Johns Hopkins Applied Physics Laboratory (APL) was running three shifts on its rented Univac 1103A, a monstrous Remington Rand vacuum tube machine. Transistorized technology was coming soon, and we had placed our order for an IBM 7090 to be delivered in 1960. But critical applications couldn't wait. Our programmers were still busily developing applications to run on the Univac.
The internal speed of the new machine would be roughly ten times that of the old Univac. We could expect, therefore, to get our then-current workload done on the 7090 in less than one shift, with plenty of capacity remaining for expanding demand.
There was just one problem: All our applications would have to be reprogrammed. Most of our Univac programs were coded in assembly language1 or in our own rather primitive higher-level language. Fortran was a recent development in the IBM world, and our programmers hadn't yet discovered it. There wouldn't be time to reprogram everything before the new machine arrived.
Remington Rand rushed to our rescue! They offered to give us the 1103A. We could have that million-dollar machine free! All we'd have to do was to pay to run and maintain it. It didn't take us long, however, to realize that such a gift would be no bargain. The cost of electricity, air-conditioning, continuing maintenance, and operating personnel would be unaffordable. Furthermore, the continued presence of that obsolete machine would reduce the incentive to convert to the IBM 70902, and further extend our dependence on the old monster. We told Remington Rand to plan on carting their machine away in two years.
Instead, we would develop an interpretive simulator to run our Univac programs on the new IBM computer. Was that a practical solution? Could we get such an ambitious piece of software ready before the Univac was to be shut down? Our Operations Manager, Lowell McClung, was sure that such a solution was practical.
We formed a two-person project team consisting of me and Glenn Slike, who brought long IBM 704-709 experience from a previous employer. I was still working as a night-shift Univac operator, but had plenty of time during long-running jobs to work on this project. Glenn and I would confer in the late afternoons.
We tested our Univac simulator at IBM data centers in New York and Poughkeepsie, and managed to have it working well by the time the 7090 was delivered in 1960 and our old Univac machine was shut down and taken away. The nearby David Taylor Model basin had a facility to convert those heavy Univac steel magnetic tapes to IBM's 2400-foot plastic reels. As a Navy contractor we had friendly relations with them, and they offered to help us convert our tape library. A few hundred essential reels of programs and data were ready by the time we needed them.
Although the IBM 7090 and the Univac 1103A were based on entirely different technologies and came from very different designers and manufacturers, they had a few things in common that would greatly simplify our effort (and contribute to the efficiency of our simulator):
But we had to deal with some serious incompatibilities, too:
Most Univac instructions were of the (binary) form:
|op. code||U address||V address|
|000000||000 000 000 000 000||000 000 000 000 000|
but a few operations substituted control information (options or count) for the U-address field.
The heart of the simulator was this simple loop. Index register 4 served as the Univac's instruction counter (PAK). Univac jump (branch) instructions could re-set it.
START CAL 0,4 Fetch current instruction PAX ,1 Extract 2nd-operand (V) address LGR 30 Isolate 6-bit PAX ,2 operation code TXI *+1,4,-1 Advance PAK TRA OPTBL,2 Perform instruction
After performing a Univac instruction the code would branch back to
The Univac 1103A had no index registers for address modification, so programs had to do arithmetic on instructions in order to cycle through an array of consecutive memory cells. To compensate the machine had a special repeat instruction which would cause the next instruction to be executed a specified number of times, advancing either or both operand addresses by 1 for each iteration. In combination with certain 2-address instructions that made common kinds of iteration, such as matrix operations, quite efficient.
When one senior Univac programmer learned of our simulator project, he exclaimed: "But it will take four hundred 7090 instructions just to simulate repeat." Actually it took just twenty-nine instructions! The same clever design characteristics3 that made the Univac's repeat feature efficient, also made our simulation simpler.
Assuming reader interest4, part 2 will explain some of the messy issues we had to confront in simulating input-output for Univac's peripheral devices. Part 3 will discuss some lessons learned and describe some political issues we faced in distributing the simulator to other organizations.
Last modified (footnote added) December 31, 2015
Return to IDI home page