Dan Espen <
des...@verizon.net> writes:
> Apparently a last minute change:
>
> A decision by IBM in May 1968 to modify the project to support S/360
> compatibility resulted in the name change from ACS-1 to ACS-360 for the
> computer being designed.
> ...
> The ACS-360 project was canceled in May 1969;
>
> So, 1 year trying to include compatibility then they threw in the towel.
> But those same "disruptive" changes did go to market:
>
> however, many of the innovations resulting from the project would
> eventually find direct realization in the IBM RS/6000...
>
> Lynn has characterized the FS project as one that put a halt to
> S/360 software/hardware enhancement.
http://www.garlic.com/~lynn/2017.html#84 The ICL 2900
Amdahl was working on 360 compatibility from the start ... but was
"disregarded" ... it wasn't until 1968 that he won the "shootout" with
the ACS-1 faction.
the description has the ACS-1 group designing a non-compatible machine,
it was Amdhal that was responsible for a 360 compatible ... and various
folklore talks about shoot-out between ACS-1 and ACS-360 ... with Amdahl
winning. Amdahl extended ACS-360 design to also include 1/3rd speed and
1/9th speed to address the whole 360 makret (rather than just high end
supercomputer). reference to "shootout"
https://people.cs.clemson.edu/~mark/acs_end.html
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.
...
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.
... snip ...
and
https://people.cs.clemson.edu/~mark/acs.html
Amdahl's opinions about the advantages of compatibility were disregarded
in 1965, and by 1967 he was quarantined by the ACS leadership because of
his continued advocacy for compatibility. In early 1968, he began
discussing a compatible design with John Earle, who sketched out a
five-gate-level pipelined implementation. In May 1968, IBM east-coast
management approved a "shoot-out" between ACS-1 and AEC/360 (the
"Amdahl-Earle Computer" proposal).
Amdahl and Earle won the shoot-out, and a decision was made to convert
the project to S/360 compatibility. Gone were the extended floating
point formats and the unique ACS-1 instruction set design. Several
members of the hardware and software architecture team left at this
point, but the project continued under Amdahl's leadership. The
compatible design was called the ACS/360, and several of the ACS
innovations undergirded the design. For example, like the ACS-1, the
ACS/360 was planned as the first computer with multiple instruction
decoding and issue, and it would also have been the first to use a
branch target buffer (called at that time "prefetch sequence control
registers").
In May 1969, IBM east-coast management rejected Amdahl's plan for three
ACS/360 models, and the project was cancelled. However, the legacy of
the ACS project extended beyond the cancellation, although sometimes
without recognition that the ideas were developed as part of ACS or
descended from ACS work. Some of these ideas include multiple condition
code registers, dynamic instruction scheduling techniques, numerous
compiler optimization techniques, branch target buffer design, I/O to
cache techniques, MECL-III high-speed ECL circuits, scan-out and FRU
(Field Replaceable Unit) techniques.
... snip ...
Ferguson/Morris 1993 "Computer Wars: The Post-IBM World"
http://www.amazon.com/Computer-Wars-The-Post-IBM-World/dp/1587981394
Describes Future System was completely different and was going to
completely replace 370 ... and 370 efforts were being shutdown ... and
the lack of 370 products during the period allowed clone processors to
gain market foothold.
The rise and fall of IBM (by senior IBM executive)
http://www.ecole.org/en/seances/CM07
Talks about the major motivation for Future System was competition from
clone controllers, the objective was to so change the architecture and
make the interface between processor and I/O controllers so complex that
there would be no (easy) entry for clone controllers.
past FS posts
http://www.garlic.com/~lynn/submain.html#futuresys
I've posted before about doing clone controller as undergraduate
at the Univ. starting with Interdata/3 ... and four of us getting
written up for (some part of) clone controller business. It
evolved into Interdata/4 (handling channel interface) and cluster
of Interdata/3s handling port/line scanner function. past
clone controller posts
http://www.garlic.com/~lynn/subtopic.html#360pcm
I also periodically tell the story about Amdahl having seminar in large
MIT auditorium in the early 70s talking about his new clone mainframe
company. At one point somebody in the audience asked how he convinced
the money people to back his company. He replied that even if IBM walked
completely away from 360, there was enough customer 360 software it
would keep him in business through the end of the century. This sort of
implies that he knew that Future System was in the works, but he claims
that he didn't know anything about it. He was also given bad time with
questions about becoming almost totally foreign company (with major
ownership and all manufacturing from outside the country).
and ... I periodically contend that John Cocke
https://en.wikipedia.org/wiki/John_Cocke
He is considered by many to be "the father of RISC"
... snip ..
started designing 801/risc during Future System period that would
be the exact opposite of the Future System complexity. I joined
the RS/6000 group in the 80s ... and my HSDT project
http://www.garlic.com/~lynn/subnetwork.html#hsdt
is credited with helping bring the RIOS chip design in a year
early. HSDT had 7M satellite dish next to the engineering bldg in Austin
and 4.5M dish in Los Gatos running high-speed satellite links. Austin
group used the link to constantly ship design to the logic simulators
(for validation) in Los Gatos and San Jose.
I then had the HA/CMP doing RS/6000 high availability and cluster
scaleup for both commercial and scientific/technical
http://www.garlic.com/~lynn/subtopic.html#hacmp
also
https://people.cs.clemson.edu/~mark/acs_end.html
Sidebar: Multithreading
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 was expected, the utilization of the functional
units increased since more independent instructions were available.
... snip ...
I've periodically mentioned that I got sucked into effort to do
multithreaded 370/195 (that was never announced or shipped).
and
Sidebar: ES/9000 high-end processors
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
128 KB I-cache
4 K entry BHT; presence of branch in BHT indicates predict-taken
five 64-bit instruction buffers
ability to decode up to two instructions per cycle (e.g., a branch can
be decoded in parallel with preceding instruction but not with following
instruction)
instructions tagged with two predicted-branch-path bits
ACE, with three effective address adders
I-ACE with two-entry queue; can execute LA instructions on its own
D-ACE with four-entry queue
SXE-ACE
BXE, for controlling branch prediction and resolution
can execute BC instuctions on its own
GXE, for executing fixed-point instructions
six-deep instruction queue, which can start up to two instructions per
cycle in certain cases (e.g., one instruction has a general register
result and the other has a storage result)
FXE, for executing floating-point instructions
six-deep instruction queue, which can start up to one instruction per
cycle
SXE, for executing the storage-to-storage, decimal, and system control
instructions register renaming
32 32-bit physical fixed-point registers (for 16 architected registers)
16 64-bit physical floating-point registers (for 4 architected registers)
two backup register assignment lists kept, one per predicted branch path
(i.e., provides branch misprediction recovery)
ability to complete (i.e., retire) up to two instructions per cycle
synchronous interrupts recognized when instruction completes
... snip ...