IBM Advanced Computing Systems -- Draft Denouement section

Mark Smotherman
last updated November 21, 2009

under construction
(This reflects my current understanding. I'm aware that there will be many viewpoints, so I appreciate your help.)

Denouement

At one point T.J. Watson [Jr.] visited and the machine was described to him. At the end he asked, "But where is the unit record equipment?" There was no answer to that. Later John Cocke described 20 parallel railroad tracks each with a train traveling 60 mph. The cars of each train were full of punched cards.

That was the bandwidth of the memory bus of ACS.

I worked (for perhaps a week) on a scheme to provide line printers scaled to the speed of the machine. Acres of printers. It was bizarre but fun.

-- Norman Hardy, personal correspondence

(Reading in-between the lines in the quote from Watson above, how much was ACS misunderstood within the company? How did it fit / not fit with the direction of the company? Lots of questions... Further comparisons with Stretch as to management not knowing or appreciating the impact... Was ACS too ahead of its time?)

-- to be rewritten --

• Amdahl returns to California in late 1964; teaches at Stanford in early 1965; named IBM Fellow
• Amdahl is asked to work with ACS project in early 1965
• Amdahl argues for S/360 compatibility at Aren House planning sessions in August 1965; "90-95% of Project Y machine at 5-10% more HW" from Kolsky notes; two mountains analogy
• project appears as if it is destined to be cancelled and written off (when?)
• Amdahl argues for S/360 compatibility so that an actual product will result in February 1967
• Amdahl frozen out of project for approximately a year
• Earle frozen out in early 1968
• over a three-month period, Amhdahl convinces Earle that a S/360 version will be faster than the ACS-1
• Amdahl and Earle sketch a design that has 2/3 the cycle time as ACS-1 and that is overall 15% faster and requires 15% less hardware
• ACS-360 wins shoot-out in May 1968
• ACS-360 cancelled in May 1969

Amdahl and Earle stood alone against the other project members. Based on the mandate given at the founding of the laboratory, the other project members felt that IBM management would never hinder their efforts at building the world's fastest supercomputer by requiring compatibility.

Harwood Kolsky, veteran of Los Alamos and the IBM Stretch project, was the official representative of the ACS project for DPD marketing in Palo Alto. Kolsky attended weekly meetings on the project, and in March of 1968, he was asked to write a critique of the project for his management. In his April 26, 1968, report he advised them that while the scientific community desired a nonstandard 48-bit and 96-bit floating-point format, such a machine would only sell three or four copies. However, just as Stretch technology had propelled the 709 to the very successful 7090, he saw the same opportunity to use ACS-1 technology to propel the S/360 to the next level of performance. He felt that a S/360 compatible machine using the circuits, fixed-head disks, and compiler optimization developed by ACS would sell many copies.

Amdahl's compatibility arguments in December 1967 included: (Kolsky's handwritten notes, pdf)

• for benchmarks like Coronet, half of the adds can be done with 32-bit precision rather than 48-bit or 64-bit
• ACS minimum time to prepare for branch is seven cycles, which means 14 to 21 instructions between branches; yet many codes have only four instructions bewteen branches
• can look for branches a little early, which give most of the gain
• for benchmarks like DTF only four of the eight branches within the inner loop can be removed and replaced with skips
• no need for three-register format; for 360 codes, only 5% of instructions are move register to register
• 360 RX instruction format reduces need for large register file
• investment can be put into improving the 360 OS rather than writing a new one for ACS

Amdahl's and Earle's compatibility arguments in March 1968 included: (Kolsky's handwritten notes, pdf)

• current ACS design needs 7 levels of logic per stage, thus 12.5 nsec cycle time; although a lean design could possibly cut it to 6 levels (but some engineers say 6 levels is not possible)
• constraints on logic depth in ACS include preshift and postnormalization in floating-point operations, too many functions, and too many registers (fan-out to selection and to function units)
• ACS three-register format and large number of registers only buys about 10% performance (fewer instructions)
• hardware solutions to branch and skip are better than software solutions
• to improve performance in ACS, prepare to branch would have to be discarded (since it cannot branch ahead more than one level) as well as the 48-bit word and extra registers - then what is the difference from the 360?
• AEC-360 needs only 5 levels of logic per stage, possible 8 nsec cycle time
• current ACS needs 265,000 circuits; AEC-360 would need only 90,000
• AEC-360 would be 2.5 times faster than ACS on code with many branches and 1.4 times faster for best ACS code
• performance/cost ratio is 4:1 in favor of AEC-360

here the politics and dynamics of the situation become unclear to me; also, when was Bertam sent to the penalty box? May '68 or earlier?

One weekend in May of 1968, Vin Learson flew to California ostensibly to directly hear argument pro and con for S/360 compatibility. However, it seems that the die had already been cast, and after a short time at the Saturday meeting, he stated firmly that S/360 compatibility was now a project goal.

This decision caught most of the ACS team members off guard; however, several of the more senior members had noticed that they were giving more and more presentations during early 1968 and knew something was being considered for ACS at company headquarters in New York. The decision to switch ACS to S/360 seemed to ignore the architectural benefits sought and obtained by the design team; so, several original project members quit and went back to New York to the Research Division, including Phil Dauber and Herb Schorr. John Cocke decided to take a sabbatical at the Courant Institute of Mathematical Sciences at New York University and while there worked on a compiler textbook with Jacob Schwartz.

more folks from Poughkeepsie came, e.g., George Werner, at this point?

Because of the architectural incompatibility, Amdahl's ACS-360 had to discard the innovative branching and instruction skipping schemes. The new design was required to provide a strongly-ordered memory model as well as precise interrupts.

simultaneous multithreading proposal in Sept. 1968 for ACS-360;
later IBM patents on multithreading (John Earle is one of the inventors listed on the '138):

• US Patent 3,728,692, J.W. Fennel, Jr., Instruction selection in a two-program counter instruction unit, files August 1971, and issued April 1973.
• US Patent 3,771,138, J.O. Celtruda, et al., Apparatus and method for serializing instructions from two independent instruction streams, filed August 1971, and issued November 1973.

  need to check these:

• P. Duggan, "Multiple instruction stream microprocessor organization," IBM Technical Disclosure Bulletin, vol. 14, no. 9, February 1972, pp. 2739-2740.
• "Multiple instruction stream uniprocessor," IBM Technical Disclosure Bulletin, January 1976, 2pp. [for S/370]

By mid-1969, circuit design problems of the ACS-360 coupled with the performance achievements of the cache-based S/360 Model 85, a slowdown in the national economy, and continued East-coast/West-coast competitive tensions within the company led to the cancellation of the ACS-360.

see the 1968-1969 entries in the timeline regarding Amdahl. Also see Gene Amdahl's side of the story in:

• Gene Amdahl, "The early chapters of the PCM story," Datamation, February, 1979, pp. 112-116.
• "Gene Amdahl Takes Aim at IBM," Fortune, Sept. 1977, p. 106+.

... more to be done to set project cancellation into perspective ...

• Amdahl rolling the dice on getting to build three machines by countering management refusal with talk of terminating ACS?,
• Oct. 1966 3-by-3 decision on rental vs. buying leading to: "activities of computer lessors had forced IBM to plan in 1968 to introduce budget cuts in 1970" [Fishman, p. 142],
• reduced growth in finances in 1969 (table source: IBM Archives timeline web pages)

  Year	Employees	Revenue	Net Earnings
  1964	149,834	$3.23B +13%	$431M +18%
  1965	172,445	$3.75B +11%	$477M +11%
  1966	198,186	$4.24B +19%	$526M +10%
  1967	221,866	$5.34B +26%	$651M +24%
  1968	241,974	$6.88B +29%	$871M +34%
  1969	258,662	$7.19B +5%	$934M +7%
  1970	269,291	$7.5B +4%	$1.01B +8%

• shadow cast by CDC lawsuit,
• role of limited sales and then cancellation of Model 90s,
• Model 195 announced in August 1969 after ACS cancellation in May, also vector processing task force started in Poughkeepsie that month,
• role of NS (Next System, or sometimes New Series) competition from Poughkeepsie
• role of internal company competition; i.e., possible Poughkeepsie mindset of allowing demo design projects in Research and ASDD to goad Poughkeepsie engineers on to better things, but working to kill outside projects whenever they got "too serious"
• corporate finance projections of money needed, based on 650, 701, and then Stretch (i.e., supercomputers too expensive for the company)
• company bureauracy (e.g., six month delay while engineers in Fishkill argued over how best to package and attach to a board the 400-pin multichip carriers that ACS wanted)

Excerpt from Gene Amdahl interview in April-June 1997, IEEE Design and Test of Computers (p. 7 and p. 13)

Amdahl: ... While I was [in California], IBM decide to set up the Advanced Computer Systems Laboratory to develop a very high-end machine. I had been named an IBM Fellow ..., and an IBM Fellow was entitled to work on whatever he wanted to, provided he did not impact the product line.
I went to work on this Advanced Computer Systems project, and I concluded after three or four months that it would be a much more manageable project if the machine were made compatible with System/360 instead of being an entirely different architecture. This did not endear me to the manager of the project, so I got sort of sent to Coventry. Anyone on that project who was seen talking to me - or me talking to them - got called out to a meeting.
D&T: So in a sense you were excommunicated?
Amdahl: That's right. They also had a very bright logic designer who had designed the most significant parts of the system they were working on, but who was virtually unmanageable. So they decided to get rid of him, and they gave him to me to work with. I told him what I wanted him to design in the 360 area, and lo and behold, we were able to get slightly higher performance at about 75% of the cost. And we wouldn't need to write a new operating system.
D&T: What happened?
Amdahl: We ended up having a shoot-out. The two of us who did the 360-compatible version won. We established that in fact we could achieve more performance at lower cost.
D&T: So you basically got a new architecture through this 360-compatible machine?
Amdahl: Yes, but the company decided not to build it because it would have destroyed the pricing structures. In the first place, it would have forced them to make higher-end machine. But with IBM's pricing structure, the market disappeared by the time performance got to a certain level. Any machine above that in performance or price could only lose money.
... I've always aimed to create a product that was useful to a great many people. So I didn't want to continue working on high-end machines at IBM when their pricing policy made that virtually impossible.

Excerpt from Gene Amdahl interview in July 2007, IEEE SSCS E-News:

(Q) Was IBM still planning ways to use your design talent?

(A) ... [discussing events of 1965] ... A few months later I was asked to consider attaching my Fellow activities to a new lab IBM was starting called Advanced Computer Systems, ACS, which would be designing a super computer, hopefully to serve the Livermore and Los Alamos labs. The project would be developing a computer proposed by a group from IBM research. I knew quite a bit about it and liked much, but not all, of the plan. I agreed to do it, but being a Fellow, I did not report to their management. For a few weeks I tried to make some changes in areas I didn't like, but to no avail. I recognized that with the requirement to develop the computer design, the technology and the total software support, that there was no way they could possibly find a big enough market to meet IBM's antitrust requirements of profitability. I didn't want to be associated with a loss-leading project, like had happened to STRETCH in the 1960s, so I thought about the problem and came up with a different approach - design the computer to be System 360 compatible and at the highest speed we could achieve. This would eliminate all of the software development cost. To make it profitable we could design one or two smaller machines with the performance spacing of the existing 360 product line, thus sharing the technology development costs over a much larger market and maybe meeting the profitability requirements.

(Q) How did you fare in the design challenge and the consequences?

(A) I presented my alternative to the project managers only to have it rejected out of hand, for they were wedded to the architecture they had developed. I was pondering how to separate myself from the impending loss leader when their top logic designer got into some trouble. The managers considered him unmanageable, but couldn't fire him so they found the solution, transfer him to me! I was delighted for he was responsible for the design of the most performance determining part of their computer. I knew that if he did the design of that part of the 360 alternative, there could be no charges of faulty design. It took a bit over two weeks to describe enough of my performance approaches before he recognized that it was really feasible to compete with the other design. He then went into it wholeheartedly and actually was able to achieve a slightly higher performance and a somewhat smaller cost. Bob Evans came out to ACS with about five technical people and they held a shoot-out. We won and I was made the lab manager. The first thing I did was have the two smaller computers costed. I then submitted the three system plan to corporate pricing. The single highest speed computer was a loss leader. The second smaller computer added made a break-even program. Adding the third even smaller computer came out with normal profit! IBM management decided not to do it, for it would advance the computing capability too fast for the company to control the growth of the computer marketplace, thus reducing their profit potential. I then recommended that the ACS lab be closed, and it was.

Innovations in ACS-360

• carried over from ACS-1 design
  • backup registers
  • 8 prefetch sequence control registers
  • multiple issue
  • fixed head disks
• new to ACS-360 design
  • SIOF (start I/O fast release)
  • precise interrupts
  • memory consistency
  • two one-bit path flags (C1 and C2) were added to each decoded instruction so that the machine could fetch past up to two conditional branches (see the Hasbrouck patent)

The ACS-360 design was based on this overall structure:

• I-unit (instruction unit), with ten 64-bit instruction buffers
• S-unit (storage unit), with a six-deep instruction stack and two effective address adders
• G-unit (general purpose arithmetic unit), with a four-deep instruction stack and 20 32-bit registers, and which can start up to one instruction per cycle
• F-unit (floating-point arithmetic unit), with a six-deep instruction stack and 12 64-bit registers, and which can start up to one instruction per cycle

In summer 1968, Ed Sussenguth investigated making the ACS-360 into a multithreaded design by adding a second instruction counter and a second set of registers to the simulator. Instructions were tagged with an additional "red/blue" bit to designate the instruction stream and register set; and, as had bben expected, the utilization of the functional units increased since more independent instructions were available.

Sidebar:

The ACS-360 structure appears to have influenced the design of the IBM ES/9000 high-end ("520-based") processors some twenty-odd years later. The ES/9000 high-end processors were structured as:

• I-decoding, with five 64-bit instruction buffers and the ability to decode up to two instructions per cycle
• ACE, with three effective address adders, one with a two-deep buffer and the others with four-deep buffers
• BXE, for controlling branch prediction and resolution, and which can execute BC instuctions on its own
• GXE, with a six-deep instruction queue and 32 32-bit registers, and which can start up to two instructions per cycle
• FXE, with a six-deep instruction queue and 16 64-bit registers, and which can start up to one instruction per cycle
• SXE, for executing the storage-to-storage, decimal, and system control instructions

Two conditional branch path bits (A and B) are added to each decoded instruction in the high-end ES/9000 processor design.

For more information on the high-end ES/9000 processors, see J.S. Liptay, "Design of the IBM Enterprise System/9000 high-end processor," IBM Journal or Research and Development, vol. 36, no. 4, 1992, pp. 713-731.

Navigation within IBM ACS pages:

Back to first ACS page

Next section: ACS Legacy