Dealers of Lightning Page 14

  "All right," McGurk said. "One by one, lets have your reaction to whether we can make this change."

  "I said, 'No, I've got a problem,'" Spinrad recalled. "McGurk went around the table and, one by one, everyone else said the same thing. 'I've got this problem,' 'I've got that problem.'"

  McGurk fell silent for a moment, then slammed his fist on the table. "Okay," he said, "we'll do it!" In this cheerless atmosphere PARC's request for a PDP-10 detonated like a grenade. It had been only a few months earlier that SDS had launched its latest scientific computer, the Sigma 7—designed specifi­cally to compete head to head with the PDP-10. Having been ordered to stage a frontal assault on IBM's market, SDS now felt tripped up by the rear-guard action launched by its own corporate brethren.

  SDS executives wasted no time in starting a campaign at headquar­ters to kill the proposal. "I was for anything that would keep them from buying that computer," recalled Currie, who outlined for the Stamford brass a scenario in which a computing trade magazine like Dataination splashed a photograph across its front cover of a DEC truck pulled up to the loading dock of Xerox PARC. Try selling a Sigma machine to another customer after that!

  Taylor maintained that his group considered the PDP-10 so self- evidently superior to the Sigma they never gave a moment’s thought to how their request would resonate in El Segundo. Yet they could not have been entirely blind to the fact that the Stamford bosses regarded big computers as fungible commodities, one very much like another. After all, these were the people who had bought the wrong computer company to begin with, then compounded the gaffe by urging it to compete in a manifestly inappropriate market. No one should have been surprised that they would regard PARC's insistence on buying a rival company's machine as an act of sheer perversity.

  The task of formally vetoing the request fell to the company's new chief information officer, a systems expert named Paul Strassmann. Strassmann's primary job was to install an SDS computer wherever Xerox cur­rently ran an IBM machine. He came with sterling qualifications, since his greatest accomplishment as the computing czar at his previous com­pany, Kraft Foods, was to junk its system of underperforming IBM 360 data processing computers and replace them with Honeywells.

  IBM's failed attempt to get him fired for this rare affront had left Strassmann with no shortage of self-confidence in his own judgment. A severe character whose Teutonic accent soon won him the nickname "the Prussian" at PARC, he imagined his greater role to be that of Xerox's technological policeman. He harbored no illusions about the stupidity of forcing SDS to compete with IBM, a move he regarded as "just a spastic afterthought" by management. But he also believed his responsibility was to ride herd on the proliferation of incompatible computers at Xerox offices around the globe. He was not about to rubber-stamp a half- million-dollar purchase order for a DEC computer to please anyone, research hotshots included. He boomeranged the PDP-10 order back to PARC with instructions to produce a point-by-point technical justification, in writing.

  This turned out to be the start of fifteen years of miscommunication and hostility between Xerox's east coast and west. "I told them to show me what the PDP-10 would do that the Sigma 7 wouldn't," Strassmann recalled. "This is what hardass corporate information officers do. They say, 'Show me a competitive analysis.' But PARC never sent one. They thought it was beneath them to show a technical analysis to the headquarters guys. They didn't know how to act like corporate citizens. They just said, 'Don't ask questions.'"

  The battle raged for weeks. The official SDS line was that the PDP's popularity over the Sigma among researchers was purely an accident of timing and would soon correct itself. As Currie, a savvy enough computer man but one whose judgment was colored by his position at SDS, recalled, "The PDP had come out a little earlier than the Sigma and they were ahead of us mostly in software." He thought the issue boiled down to "a question of religion," and the least PARC could do as a new Xerox facility was try a new theology on for size. In Stamford the battle was viewed even more simple-mindedly. Headquarters execu­tives thought of software as the gobbledygook that made a machine run, like the hamster driving the wheel. They could not understand why the decision between the PDP-10 and the Sigma needed to be any more complicated than, say, choosing an albino rodent over a brown one.

  But from a technical point of view, the issue was hardly that casual. Software was the factor that defined the fundamental incompatibility between the Sigma and PDP machines and the superiority, for PARC's purposes, of the latter. The architectures of the two computers were so radically different that software written for the PDP would not prop­erly fit into the memory space the Sigma allocated for data. Even if the program could be made to run—a doubtful prospect—it would require nearly twice as much memory to run as fast on the Sigma as it did on the PDP-10. Given the high price of memory at the time, this was a major shortcoming.

  Although it was theoretically possible to simply "port" all the PDP software over to the Sigma, the CSL engineers calculated that such a job would mean rewriting every single line of every PDP program, a task that would take three years and cost $4 million.

  "The only lie in the analysis we did," Lampson later remarked, "was that we never could actually have done it because you couldn't have motivated people to do such a pointless thing."

  This was, indeed, the very technical analysis Strassmann had demanded. He received it, too, as part of the lab's capital request—but because it focused on software costs it was not the sort of analysis he expected, which would have been a hardware-by-hardware compari­son of the two machines.

  "In a way we were cooking the books," Lampson stated later, "but actually this was a pretty accurate way of turning the facts about doing computing research into dollar numbers that Strassmann could under­stand."

  Meanwhile, Taylor invited a group of El Segundo designers to Palo Alto for a two-day "discourse" on the technical issues. His goal was to persuade them that the Sigma and PDP-10 were not really competing in the same market, and they should therefore back off. Instead of engaging in the civil dialogue he had hoped for, however, his cocksure engineers pitilessly dissected the Sigma's shortcomings in front of its designers and Pake, who was sitting in.

  Taylor had to admit that the affair was a complete frost. "It ended up like a trial," he said. "Butler and Chuck Thacker knew the Sigma system very well, and they just demolished the Sigma 7. They gave the SDS peo­ple fits." When the inquisition finally concluded, Pake took Taylor aside. "You sure know a bunch of smart people," he said. "Butler Lampson seems to understand those guys' machines better than they do."

  Neither side seemed able to budge, despite Pake's efforts to find grounds for a truce. He recalled "I asked my guys, 'Is there any way we can reconfigure that Sigma machine and make it work?' The answer kept coming back no from everybody. Meanwhile we talked to SDS to see if they were interested in making any changes. They weren't. They wanted to sell us whatever they had."

  Pake's desperation communicated itself to the computer scientists. The choices indeed looked bleak. They could accept the Sigma, which meant suffering with an inadequate machine and knuckling under to the corpo­rate suits the very first time their interests conflicted. Or they could stand their ground and browbeat Xerox into buying them the PDP "But that would cost us so many brownie points we figured it was not a good idea," Lampson recalled. Not a few times in the heat of discussion was the sug­gestion heard that they should all just quit.

  Yet a different impulse, one much more powerful, was beginning to assert itself. This was the engineer's equivalent to the "fight or flight" syndrome, the instinct when confronted by an obstacle not to back off, but to barrel through it.

  "We started having these long discussions," Alan Kay remembered. "I was saying, 'Let's not chuck our badges in just yet. Let's think it through.'" Someone else suggested that perhaps they were looking at the question from the wrong end. They had made an issue out of hardware—what machine to buy—when their real concern was softw
are—what programs they could run. What if they simply built their own machine to run the programs they needed?

  Asking the question was the same as answering it. "The talk," Kay said, "turned to how long it would take us to build our own PDP-10." The answer was about one year and less than $1 million. The truth was that Xerox had only forbidden the lab to buy a PDP-10. Nobody had said anything about cloning one. 'We were fearless," Lampson recalled. "We had built this BCC machine which was a substantially more complicated and elaborate machine than a PDP-10. And furthermore the underlying technology was evolving very rapidly, so we actually had much better physical resources at our disposal. We had great confidence that we could build this thing with a fairly modest investment of effort, and very little risk. Which turned out to be absolutely correct." The machine, he said, "was not built because Xerox refused to let us buy a PDP-10, but because we thought it was the path of least resistance."

  Work on the clone began in February. Thacker assumed the role of project manager as well as the bedrock task of designing the internal logic. The other jobs got apportioned out to the lab members willy-nilly, as among townspeople at a community barn-raising, often with little rela­tion to the work in which they were most expert—but then, anyone who could make it through Taylors selection process was assumed to be smart enough to learn anything. Lampson was an operating systems designer nonpareil, for example, but with Tenex they already had their operating system. So he was dragooned into designing the central processor, a hard­ware task unlike anything he had ever undertaken in his life.

  Another who got swept into the project was Ed McCreight, an ex- Boeing engineer of unshakably sunny disposition who was still in his first week or two on the job, "rummaging around for something to do." No one could remain in that state for long at PARC. Thacker lassoed him into designing the disk controller, a hardware unit that would supervise the way the machine moved data to and from a spinning magnetic hard disk. McCreight recalled, "I told him, 'I don't know squat about disk con­trollers but, hey, I'm game. If you promise to answer all of my questions I'll do it.'"

  They all were game because they viewed the task as the construction of their own laboratory. One principle Taylor imparted to his people was that the things they built had to be designed for daily use. Too many research labs turned out playthings and prototypes designed to go on a shelf, as though merely for display.

  "They show wonderful things and nothing much ever comes of them," he complained. That would not happen on his watch. They would build nothing that could not be put to work, because that was the only way to find out in the end if the stuff was any good.

  This rule would become one of the hallmarks of PARC's creative method. Undoubtedly it held special meaning for the CSL members who had lived through the painful saga of Berkeley Computer, whose machine relied too much on idealistic designs and not enough on working pragmatism. As Kay recalled, "Within a couple of weeks after the BCC people showed up Butler got up at a meeting. BCC had failed and he was still venting. He said he was sick and tired of the six­ties, when your stuff 'sort of worked and you could usually get it to work long enough for a demo, but that was about it. He said we should decide never to make something at PARC that isn't engineered for a hundred users. If we were building a time-sharing computer, it should support a hundred people, a network should take a hundred connec­tions, and so on. Our initial reaction to that was, 'Gee, it's really going to cramp our style.' But in fact the extra thought we had to put into everything in order to support it for a hundred users made things work so much better that it probably sped us up by a factor of three."

  The idea that they were building their own computing environment galvanized them into working at breakneck speed, like settlers hastening to erect a rudimentary shelter before the onset of a hard winter. An almost alchemical change overtook the lab, infusing it with the pure excitement of discovery that a research manager may be lucky to witness once in a lifetime. People would contend later that being forced to clone the PDP-10 was the best thing that ever happened to CSL—even Strassmann eventually bragged, "I made everyone a hero." This is the period they were referring to, when a bunch of disparate talents came together in appreciation of the virtues of working together on challenges that had virtually no precedent and the air filled with new ideas. Then there was the added satisfaction of testing their mastery of a new technology. "It was fun," Lampson said later, "to see how easy it was."

  The fundamental problem was that to the extent the PDP-10's phys­ical design belonged to Digital Equipment Corporation it could not simply be copied, at least not legally. In any case, no one at PARC had spent enough time inside that machine to reproduce it circuit for cir­cuit. The trick was to turn this limitation into an advantage. Since the task at hand was not really to build a PDP-10, only a machine that would follow the same instructions as a PDP-10, there was no reason not to find a shortcut. The best shortcut, as they all knew, was to substi­tute their own microcode for the PDP-10's wiring.

  DEC's machine, as it happened, was the epitome of the "hard­wired" computer. Its operation depended on the physical configuration of its transistors; these were arranged into intricately linked "gates"— the building blocks of traditional digital computers that received electrical impulses at one end and passed, propagated, blocked, or modified them according to the rules of binary mathematics and nine­teenth-century Boolean logic.

  From thousands of these devices, artfully arranged, could be con­structed a machine able to add, subtract, multiply, and divide; read a character from a teletype and output it to a cathode-ray screen; or fore­cast the trajectory of a launched missile. But it was no longer necessary to fashion the gates out of wires and transistors. In place of much of the PDP-10's intricate circuitry the CSL engineers planned to substitute a class of software known as microcode.

  One can think of microcode as a way of allowing digital signals to replicate the twists and turns of a hard-wired machine's circuits with­out actually traversing the physical pathways. Microcode examines a programmed instruction, determines where it would end up if it primly followed all the wiring, and deposits it in the right place without making the arduous overland trek.

  Microcode's great advantage over hard-wiring is that, as Lampson notes, "it's much easier to express something complicated in program instructions, or micro-instructions, than directly in gates." Detect a bug in a hard-wired machine and you have to rip out the errant circuits and solder in new ones. With microcode you just rewrite the program. It is as though in traversing the United States from Boston to San Francisco you find that the paved highway through Cincinnati leads not to San Fran­cisco but San Diego. Microcode would be the equivalent of getting on an airplane and changing the flight path rather than ripping up and relocat­ing the highway.

  Translating hardware into software in quest of this simplicity is, as processes go, fiendishly complex—the digital signals take a lot more twists and turns in microcode than in a hard-wired machine; but to Tay­lor's group its mysteries were an open book. The BCC 500 was micro- coded, as was the FLEX machine Kay designed for his Utah doctorate.

  "We knew a lot about microcode," recalled the latter, who contributed some conceptual ideas while observing CSLs actual design and construc­tion of the machine from the sidelines. "One of the world's great micro-coders, Ed Fiala, was with us, so that was a big plus. One of the great hardware designers, Thacker, was there, that was a big plus. The minus was that there were only about ten people to do it all. And it had to be done quickly."

  Once they settled on the new course of action, a whole world of possi­bilities suddenly opened to them. They could not only clone the PDP-10; they could improve on it. The first place to do so was the memory. PDP machines used ferrite core memory, the standard in the industry since its invention in 1951 by Jay Forrester at MIT. Core memories were made of tiny rings (or "cores") woven into a mat of copper filaments that allowed each ring to be magnetically polarized. The cores held, or "remem­bered
," their charge until deliberately overridden, leaving a pattern to be read back and interpreted as data bits in storage.

  Core's great virtue was its reliability. But it had to be manufactured by hand and suffered from the defects of great bulkiness and slow speed. The 300-kilobyte core memory of Wes Clark's TX-2, for instance, was a handmade block of about a cubic yard, or the size of a large file cabinet, costing roughly half a million dollars. This volume of memory was large for its time but trivial by todays standards, when a desktop computer's semiconductor memory can hold about one hun­dred times as much information in the physical volume of a couple of credit cards, at a cost of about forty dollars.

  By 1971 core memories were about to be supplanted by a brand-new technology based on silicon semiconductors. The previous October a one-kilobit memory chip (that is, 1,024 bits of memory per chip) had been introduced by Intel, a young engineering company co-founded by Gordon Moore of "Moore's law" fame. Intel's 1103 chip was struggling for acceptance in the computer indus­try, largely because its peculiarities gave system designers migraines. The 1103 memories were "volatile," meaning that all the stored data were wiped out whenever the chip's charge was lost. Because the 1103's charge had a tendency to gradually leak away, the chip had to be recharged, or refreshed, by zapping it with an electrical impulse several thousand times a second to keep data from evaporating. (Cores, by contrast, were "non­-volatile," meaning they held their stored data indefinitely, charged or not.) The 1103 required users to supply it with all sorts of "weird volt­ages," as Lampson later put it, and looked like it might be prone to a host of data errors arising from the density at which designers crammed it with microscopic transistors.