Yesterday's story about the secret cryptanalytic Harvest left a small but beautifully dangerous tail in IBM's archive. After the failed Stretch, the corporation launched two projects: X was supposed to be 10–30 times faster, and Y — a hundred times. The second spawned ACS-1: a supercomputer so ambitious it never even made it to hardware. It was canceled on the drafting table.
Inside ACS-1 in 1966, Lynn Conway and colleagues described dynamic instruction scheduling: the processor picks ready work not strictly by program lines, but wherever there are no dependencies. Today this is called out-of-order execution; without it, modern CPUs would look like a supermarket checkout that as a matter of principle only serves whoever grabbed the yogurt first. On top of that, IBM fired Conway the year ACS was canceled, and her name along with the project nearly dissolved in the fog of corporate secrecy.
This is not a story in the "brilliant idea was too early" genre. Such formulas are intellectual band-aids used to cover up failures. ACS died because three entirely earthly forces collided at IBM: compatibility, price, and internal power. And the ideas outlived the machine because the physics of transistors twenty years later finally caught up with their appetite.
Stretch, IBM's early 1960s supercomputer, turned out to be a painful lesson: marketing promised too much, and real performance didn't meet expectations. In August 1961, IBM started two response projects. Project X in Poughkeepsie eventually spawned the System/360 Model 91 and 95 line; Project Y in Yorktown Heights got a far crazier assignment — build a machine 100 times faster than Stretch.
When Seymour Cray showed off the CDC 6600 in 1963, IBM got its competitive spirit back. In 1965, CEO Thomas Watson Jr. ordered a "go-for-broke" program — in Conway's recollection, almost a Manhattan Project, except instead of a bomb they were building a computational monster. The Project Y team was moved to California; first they sat in an old fruit warehouse on Kifer Road in Sunnyvale, then got a new building on Sand Hill Road in Menlo Park, near the Stanford Linear Accelerator.
ACS-1 was conceived without compromise: 48-bit numbers, 96-bit double precision, 10 nanosecond cycle, six-seven logic levels per pipeline stage. The goal was performance a thousand times higher than the IBM 7090. The machine was planned to have cache, fast I/O directly into it, fixed-head disks, virtual memory, and an optimizing compiler. A potential customer — Livermore Laboratory — was even preparing to receive IBM engineers and expected a prototype by summer 1967.
In participant Norman Hardy's recollection, Watson once asked where this machine's punched card device was. John Cocke answered with a metaphor: imagine twenty parallel railroad tracks, a train going 60 mph on each, cars packed with punched cards. That's the bandwidth of the ACS memory bus. For data output, Hardy once designed "acres of printers." But the most precious part of ACS-1 lived not in buses and punched cards, but in how the machine chose the next instruction.
A classic processor loves discipline: first instruction #1, then #2. But a real program is a dependency graph, not a queue at the passport office. If the first operation is waiting for data from memory, and the third is ready right now and doesn't depend on the first, it makes more sense to send the third to a free execution unit. Then carefully return the result as if no anarchy ever happened. This is out-of-order execution.
An internal IBM ACS memorandum dated February 23, 1966, signed by L. Conway, B. Randell, D. P. Rozenberg, and D. N. Senzig, calls the technique dynamic instruction scheduling — DIS. The authors honestly explain why it's needed: a compiler can arrange instructions nicely, but can't predict memory delays and competition with autonomous I/O in advance. So scheduling has to be moved inside the machine, where the real state of operands and functional blocks is visible.
In ACS, arithmetic and address blocks had queues; ready instructions could be selected from them and several launched per cycle. Conway developed a bit-matrix that tracked what was ready and what was waiting for a result. The team called the hardware either "contender stacks" or instruction queues; today we'd say instruction window. The name changed, the principle remained — and that's exactly how high-performance processors work now.
It's important not to slide into the legend of a single inventor. IBM already had Robert Tomasulo: his algorithm for the System/360 Model 91 floating-point unit is another crucial route to out-of-order execution. The DIS memo itself references earlier schemes by Amdahl, Chen, and Thornton. Engineering history rarely resembles Newton's apple; rather, it's several teams simultaneously arriving at the same narrow bridge because the road ahead physically doesn't exist without it.
But ACS had a particularly bold reach: not a separate block, but a generalized architecture with multiple issues per cycle, a hardware scheduler, cache, and an aggressive compiler. In 1966 this was a project of the future that lacked future transistors. And until they grew, the machine had to survive a tournament where the rules were written not by physics, but by its own corporation.
Gene Amdahl argued almost from the first meeting an unpleasant thought for romantics: a supercomputer must be compatible with System/360. Otherwise the customer would have to throw out software, compilers, processes — in short, buy not acceleration but a new planet. Amdahl believed that an S/360-compatible machine would retain 90–95% of promised performance, adding only 5–10% hardware. The ACS team initially ignored this, and by 1967, according to his interview, effectively sent him "to Coventry": everyone who met with him was soon called to a separate meeting. Corporate distributed consensus system, only with worse UX.
Then John Earle appeared — a brilliant but confrontational circuit designer whom management gave to Amdahl as punishment. This produced a beautiful side effect of organizational error: Amdahl and Earle sketched out AEC/360, a compatible alternative. By their estimates, it ran on an 8 ns cycle versus 12.5 ns for ACS, required about 90 thousand circuits instead of 265 thousand, and gave a performance/cost ratio of 4:1 in its favor.
These figures were not physics's final verdict. In April 1968, a committee compared projects on five benchmarks; AEC/360 had no simulator, and timings were counted by hand using Amdahl's optimistic 8 ns forecast. Carl Conti nevertheless recorded an inconvenient conclusion: ACS's architectural advantage on a number of tasks was around 10–20%, and dependence on compiler optimization quality could eat it up. That is, ACS didn't lose because it was bad, but because its proof of superiority hadn't yet become proof.
In May 1968, IBM ordered the project redesigned for System/360. The original instruction set and extended number formats went overboard; part of the team left, including Herb Schorr. Cocke took academic leave. ACS/360 retained some ideas — multiple issue, predicted branch target buffers, precise interrupts, backup state registers — but it too didn't live to become a machine. In May 1969, IBM shut down the entire project.
If you stop at "compatibility beat pure architecture," you get a neat but incomplete fairy tale. In 1968, more than 60% of IBM's 26 thousand installed systems were S/360. Models 30 and 40 gave 32% and 35% system profit, Model 65 — 24%; top Models 75 and 85 together ran at a 17% loss. IBM wasn't a philanthropic foundation with a calculator loose in the server room. Its cash engine lived in the mid-segment.
Amdahl proposed a three-tier ACS/360 lineup: a flagship, a version at a third of its performance, and another at a ninth. In his recollection, corporate calculations gave this picture: one supercomputer — loss leader; with a little brother — break even; with all three — normal 30% profit before taxes. IBM refused anyway.
Watson later explained this with an image that hurts an engineer slightly but is hard to argue with: IBM couldn't compete with Control Data in supercomputers "for the same reason General Motors can't compete with Ferrari in two-hundred-mile sports cars." Such a machine didn't fit the product line, familiar sales, volume, and target margin. ACS wasn't canceled because it ran out of engineering; IBM ran out of business model for this engineering.
Against this backdrop, a rumor retold by Amdahl and Max Paley sounds especially ironic: what if a research supercomputer was originally acceptable to develop, acknowledge the market as too small, cancel the product — but distribute its technology across other products without the heavy R&D tail? There's no proof of intentional sabotage, and turning rumor into verdict would be cheap conspiracy theory. But the mechanism of "internal moonshot becomes idea library after cancellation" looks uncomfortably plausible.
ACS's cancellation had a human cost. In 1968, Conway was preparing for gender transition and tried to arrange with IBM for a quiet transfer after recovery — under a new name to a different Bay Area division. Her managers and colleagues supported the plan. Local HR escalated the question upward, and corporate leadership canceled it.
In her retrospective, Conway quotes IBM's wording: her presence after transition would supposedly cause colleagues "extreme emotional distress." The people who made the decision never even met with her. The company effectively demanded she sign termination papers in exchange for a six-month consulting contract; after divorce she lost contact with her children. The same 1968 threw out of IBM both the project and the person who helped the project think faster.
Then the story makes a turn that should make any architecture lover's eyes itch. Conway started over as a contract programmer, then became an architect at Memorex, and in 1973 came to Xerox PARC. There, together with Carver Mead, she changed not the execution of programs, but the way of designing chips themselves.
The book Introduction to VLSI Systems came out in 1980; by 1983 nearly 120 universities were using it, and sales exceeded 70 thousand copies. Scalable design rules and multiproject wafers let digital engineers build complex silicon systems without simultaneously becoming semiconductor manufacturing physicists. The MPC79 experiment and subsequent MOSIS infrastructure became an early prototype of the fabless model: separate concept, design, and fabrication so a small team could even get to silicon.
The result is almost defiant symmetry. ACS-1 tried to make a machine on-the-fly choose useful work instead of dumb waiting. The Mead–Conway approach made the industry choose useful work instead of waiting for a huge company with its own fab to let you make a chip. In both cases, Conway removed an artificial bottleneck: first for instructions, then for people.
While the idea gained new scale, its author carefully chose the opposite — disappeared from history. In 2018, Conway gave this phenomenon a name: the Conway effect. Her definition is calmer and scarier than intentional conspiracy: people tend not to notice innovations from those from whom innovations aren't expected. Even seeing something new, they attribute it to a "known innovator." So history becomes not an evil editor with a red pen, but an automatic ranker with broken weights.
She didn't claim all colleagues stole her work. On the contrary, the original DIS memo is signed by four authors, Tomasulo's role in Model 91 is separate and large, and ACS spawned many lines of inheritance. The precise diagnosis is stronger than a convenient legend: secrecy didn't allow the project to form public reputation, cancellation scattered the team, and then Conway's personal biography forced her to work in hidden mode. A few ordinary organizational processes are enough for a name to disappear without a single villain in a chair.
IBM publicly apologized to Conway only in 2020 and awarded her a Lifetime Achievement Award. The apology is the right gesture, but not a time machine. ACS-1 won't appear in a museum, and its authors won't get a chance to test that very bold design against real silicon. But memorandums, simulators, archives survived, and one important engineering moral: a canceled project can be a product failure but still remain a technological deposit.
The ACS-1 story is useful precisely because it doesn't let you choose a convenient culprit. Amdahl was right about the software ecosystem and product economics. The ACS team was right when building an architectural leap. IBM was right to fear an unprofitable flagship — and simultaneously lost the chance to turn its lab into a real supercomputer answer to CDC. This is not a tragedy of stupidity; this is a tragedy of different metrics having different owners.
The strongest part here is the two-decade delay. An idea can be correct but not cheap enough, not verifiable enough, in the wrong lineup, and without a political patron. When transistors, markets, and compilers grow up, someone later calls it "obvious." Engineering memory is cruel: it loves the finished product and poorly remembers canceled blueprints, though sometimes that's exactly where the source code of the future lies.
And Conway is the best counterargument to the corporate phrase "we closed the topic." No, you closed the budget and building access. The idea got out, changed scale, outlived the hardware, and ultimately reached every laptop, smartphone, and chip that tries not to waste cycles. A good engineering ghost: doesn't make noise, doesn't take revenge, just turns out to be everywhere.