Mod 30 Emulation of 1401
A series of e-mails in 2012, - between Fred Brooks and Robert Garner
|
Subject: Re: 1401 emulation on M30 story and Model 60 discussion (was Fw: Can we chat about Wilkes and 360 history? (was: Fw: "1401 emulation on 360" essay and a few other questions From: Robert B Garner Date: Fri, Jan 27, 2012 3:19 pm To: brooks@cs.unc.edu ... p.s. Reviewing my notes from our conversation: I understand that during the design phase of the NPL models, the design teams preferred "conventional sequential" (hard-wired) logic over microstore-based control logic. Since your preference was microcode, you had set a bar where each model design team had to demonstrate that hard-wired logic would offer a 25% cost-performance advantage over microcode. You said that it was a "horse-back" decision (i.e., obvious) for model 30, 40, and 50, but that the model 60 team (NPL 400) had actually built the first version using hard-wired logic and then switched their minds and decided that microcode had better cost-performance. From "IBM's 360 and Early 370 Systems," page 160: "But in the fall engineers discovered a way to operate the read-only control store of the mid-range NPL 315 [M50] at a higher speed--one sufficient for the needs of the faster NPL 400 [M60]. Joseph L Brown, the Model 400 engineering manager, made a risky decision to substitute the faster store for conventional control circuits. This was a drastic change so late in development, but Brown was emboldened by the possibility of finding a solution to the conversion dilemma." And from page 169, about the April 7th announcement: "For television camera, Evans demonstrated a System/360 Model 60. The running model contained conventional circuitry for control because it had been built before the NPL 400 designers, only six months earlier, had turned to read-only store control." Do you know if Joseph Brown, NPL 400 engineering manager, or Stuart Tucker, system design manager, are still with us? So, the Model 60 originally had 2-microsecond core memory, which was never shipped (and was used in the hard-wired control logic demo prototype). And it was replaced with the 0.75 microsecond core memory Model 65. From this table, the model 65 control store originally had a 0.25-microsecond control store access, matched to its clock cycle time (shipped at 0.2 microsecond), and thus would have been quite a bit faster (8x) than a 2-microsecond core memory, so I see how the microcode based design would have cost-performance effective in that case. However, a 0.75-microsecond core memory would have been only 3 times faster than the control store, so I wonder if hard-wired logic would have actually resulted in higher performance in that case; i.e., the control store control logic would be a performance bottle neck? But then Brown would not have his achieved his emulation goals...
Tables from the 1964 JR&D "360 Implementations":
|
|
From: Robert B Garner/Almaden/IBM
To: brooks@cs.unc.edu Date: 01/09/2012 11:58 AM Subject: Re: 1401 emulation on M30 story (was Fw: Can we chat about Wilkes and 360 history? (was: Fw: "1401 emulation on 360" essay and a few other questions Fred, It was such a pleasure speaking with you today! You answered many questions that had been on my mind, and further enhanced my understanding of those times. Here is the text that you wrote in 2009 describing the fire drill of figuring out how to emulate the 1401 on the model 30 and your "elation" on pulling it off. I would like to post this within the history section of our 1401 restoration web site, http://ibm-1401.info/1401Origins.html, and likely eventually use it/refer to it in a future 1401 history article. Do you recall the "one minor modification" to the model 30 data flow? That was truly the only mod? (Given the fixed-width'ness of the 360 vs. the variable-length-ness of the 1401, that's interesting.) Best Wishes, - Robert ... |
third most recent
|
From: Fred Brooks Date: March 19, 2009 6:44:25 AM PDT ... Robert, One day in January of 1964, as the System/360 was tearing along for an April 7 whole-family announcement, John Haanstra, brilliant engineer and great manager, President of the General Products Division (who had been opposed to the S/360 plan all along so far as the 1401 family went), sprung a surprise. He convened a multi-day meeting of the Group executives in White Plains and pitched the (quietly developed) 1401S as an alternate product plan for the lower part of the market, instead of the S/360 Models 20 and 30. These latter were in his product responsibility, but he had grudgingly let them be developed in his labs. The 1401S was to be 6x the 1401, at least upward compatible from the 1401, and priced the same as the 1401. The argument was indeed based on Honeywell's Liberator, which was, I believe, more than software—I recall it as having a hardware-assist to help emulation of the 1401. (Centefelli's recollection is probably more accurate than mine.) Haanstra's argument was that the incompatible S/360 Models 20 and 30 would essentially give away the 1401 market to Honeywell, whereas the 1401S, although it would impact 1401 rental revenue, would make a lot of money. It was a potent argument indeed, both in substance and in timing, because the Liberator was the panic du jour for the company brass. This proposed change would have been a death blow for the S/360 family. The 1401 market was more than half of our total forecast in terms of number of machines, and perhaps half in $. Spreading the software cost over half the revenue would have ruined our prices. Moreover, the 1401S would have taken a big share of the Solid Logic Technology chip production, which turned out the be the limiting factor on delivery schedules. We had the DSD-invented emulator technology rolling vigorously for the 7090 on the Model 60. So Evans and I immediately thought that afternoon of seeing what we could do for a 1401 emulator. I called Poughkeepsie and Endicott and set up the plan. William V. (Bill) Wright and Gerald (Gerry) Ottoway were my two-person technical cavalry team, genius computer hardware and software designers that I sent to wherever the battle was thickest. They had helped turned around the Böblingen lab technically from a 1401-ish little machine to the Model 20, after we had won that political battle, so they were intimately familiar with 1401-ish dataflows and S/360-ish microcode. They and I severally flew to Endicott that night, where we joined the chief architect of the Model 30, William (Bill) Hanf. The three of them designed and microcoded all night, while I listened, approved sub-decisions, cheered, and kept fetching the coffee. By dawn we had a design that required one very minor modification in Model 30 dataflow, and we had actual microcode for the instruction-fetch-decode loop and all the most common operations. We had timed it on 1401 instruction mixes and knew that it would run 4x the 1401, at least. Yes, I was elated! I caught the early morning flight from Endicott back to White Plains and presented these new results at the second day of the meeting. What our new plan offered was 1401 compatibility and an easy customer transition into S/360 and hence the growth and future mainstream. Needless to say, this new development was as startling as Haanstra's assault on the official company product plan had been. The meeting adjourned, to come back on the third day. Lots of discussions went on in White Plains that night. When we convened the next morning, Haanstra wasn't there. He had sent Ty Marcy, his Division Manager of Engineering, to represent GPD. I knew then we had won. What had happened overnight was that John Opel, then President of the Data Processing Division (field marketing and sales force), decided that our plan represented the right way forward for the company. His reasoned and influential voice convinced the top brass. From then on, the company really united in making S/360 happen, and we announced on April 7 as planned. A little while later, Haanstra left to become head of computers for GE. Of course, the emulator microcode generated that night had to be checked, expanded to cover all operations, and productized. All that happened in due course. Fred |
fourth most recent
|
----- Forwarded by Robert B Garner/Almaden/IBM on 01/09/2012 11:41 AM -----
From: Robert B Garner/Almaden/IBM
Fred,
I'm scheduled soon to give a narrative talk on CISC vs. RISC, based on my perspective of having designed one of each in my career (e.g., the Xerox STAR and Sun SPARC).
I have several questions about Wilkes and IBM's 360 history that I would like to run by you. Would you have an opportunity to talk on the phone later this week or next? I would be greatly appreciative of that opportunity. Best Wishes, - Robert p.s. My essay "Early Popular Computers, 1950 - 1970" is now posted on the IEEE History Network web site: http://www.ieeeghn.org/wiki/index.php/STARS-Article:Early_Popular_Computers,_1950_-_1970
|
fifth most recent
|
----- Forwarded by Robert B Garner/Almaden/IBM on 01/09/2012 11:41 AM -----
From: Robert B Garner/Almaden/IBM
Fred, I'm scheduled soon to give a narrative talk on CISC vs. RISC, based on my perspective of having designed one of each in my career (e.g., the Xerox STAR and Sun SPARC). Although CISC and RISC were popular marketing "fighting" terms, I would argue that they're a bit technically misleading, particularly as I've come to understand computer design tradeoffs made before the 1970s. I have several questions about Wilkes and IBM's 360 history that I would like to run by you. Would you have an opportunity to talk on the phone later this week or next? I would be greatly appreciative of that opportunity. Best Wishes, - Robert p.s. My essay "Early Popular Computers, 1950 - 1970" is now posted on the IEEE History Network web site: http://www.ieeeghn.org/wiki/index.php/STARS-Article:Early_Popular_Computers,_1950_-_1970
|
sixth most recent
|
----- Forwarded by Robert B Garner/Almaden/IBM on 11/02/2011 05:42 PM -----
From: Robert B Garner/Almaden/IBM
Fred, First, I wanted to say that I enjoyed your appearance in IBM's Centennial film: "They Were There - People who changed the way the world works." http://www.youtube.com/watch?v=XrhDaAmn5Uw It also reminded me of our on-going correspondence, which I much appreciate. Would you now have an opportunity (now that your book has been published) to update your "1401 emulation on 360/30" story (below)*? I would like to post it on the history subpage of our 1401 site and possibly use excerpts in a future 1401 article. However, you had indicated you wanted to refine it first. Also, I have just a few other questions.. ;-) 2) In your mind, what were the key motivations for the microstore-based NPL models during the planning and design process? Was it primarily driven by expected lower implementation cost? (Was there a paper study that documented cost benefit? In the end, did the cost of control store come out larger than expected?) Or control store's flexible capability for field upgrades/bug fixes? Was there any consideration for emulating the families that NPL would be superseding? (700, 7070, 7090, etc? Not the 1401!). 3) Do you recall any more anecdotes about the bake-off between the 101H and 1401-S projects? pgs. 162-163 in Bashe et al makes it sound like a charged cat fight, with some folks caught in the middle on both sides. Where you at the Feb/64 meeting when1401-S was canceled? Do you recall anything more that hasn't already been said ? 4) Reading the 1401 entries in your Blaauw/Brooks Computer Architecture textbook, I see that your main criticisms of the 1401 are of the undocumented operations and side effects that unfortunately programmers readily discovered and adopted (and were unexpectedly tripped over in the 360 emulation work I assume). From my early training at Xerox SDD/PARC on the Mesa ISA PrincOps document (which may have been inspired by the meticulousness of the 360 PrincOps) and as the lead SPARC architect at Sun, the process of completely and explicitly defining every instruction operation and side effect was a pivotal requirement for a good architecture. I assume this wasn't a prime consideration on Fran's mind for the 1401, given that unit record control panels already embodied unspecifiable behaviors and undefined outcomes?** Any thoughts now? 5) Speaking of your architecture book, on pg. 98, the 1401 is described as having a 6-bit byte, where you wrote: "Byte resolution was introduced by the 702 series and continued in the 1401 and the 360...and PDP-11 ... and 8080.." I understand that Buchholz wrote of a byte as the "unit used to encode a character and for use in IO," *** but the 1401 folks and manuals all use the "character" or "location" notations. Ironically, given the 1401's word mark bit and parity bit, its memory byte capacity is actually 8 bits! Did anyone in 702/705 land ever use the "byte" term? Or did it only catch on with 360? Any thoughts in this era? 6) I understand from reading Pugh et al IBM's 360 and Early 370 Systems, pg 143 - 146, that your original thinking (facing the large number of 1400 sales, I assume) for accommodating shorter instruction formats for low-end NPL machines was a stack architecture (concept from Backus), but you soon realized the negative cost and speed implications and "decided to hold a 30-day design competition wherein teams formed of one or more members would each submit an architecture. After these submissions had been presented and discussed, you would select a winner [May 1986 conversation]. Amdahl set forth the competition ground rules... Amdahl, Blaauw, and Peacock each headed teams and ten others were formed. You were careful to keep your own counsel during the competition ... on a sketch kept in a secret drawer. You guided a selection that drew principally on the Amdahl and Blaauw entries. Arithmetic operations on decimally encoded operands of variable length were defined as memory-to-memory instructions, as in the 1401." Questions: Who suggested the 1401-style variable-length memory-to-memory instruction formats? Amdahl, Blaauw, or you? Rationale? Do you recall what your suggestion was on your "secret sketch"? 7) Do you recall how the old 48-character unit record equipment (403, 407 etc) used the lozenge character? I can't find anybody who recalls! And why they didn't have the "+" or "=" character? You would have thought that business folks would need to add and equalize? ;-) Those poor FORTRAN guys... I trust I haven't asked too many questions! ;-) Sincerely, - Robert * One of the 1401 designers, George Ahearn, is part of our volunteer restoration team, and worked on the 1401 emulation microcode. ** Fran is very much in tune with mathematical/logical rigor. He told me stories of John von Neumann consulting on intricate Endicott ASDD projects. Fran is actually very mathematically inclined and was a close friend of an ASDD mathematician, Mitch Marcus, who wrote the textbook Switching Circuits for Engineers. Fran first learned about switching circuits from one of Claude Shannon's first PhD students, and then taught the class, inspiring Mitch to take it over. *** From Buchholz's Planning a Computer System, Project Stretch, pg 40: "Byte denotes a group of bits used to encode a character, or the number of bits transmitted in parallel to and from input-output units. A term other than character is used here because a given character may be represented in different applications by more than one code, and different codes may use different number of bits (i.e., different byte sizes). In input-output transmission the grouping of bits may be completely arbitrary and have no relation to actual characters. (The term is coined from bite, but respelled to avoid accidental mutation in bit.)
|
seventh most recent
|
----- Forwarded by Robert B Garner/Almaden/IBM on 03/02/2011 02:41 PM -----
From: Robert Garner
Sent from my iPhone
Begin forwarded message:
From: Fred Brooks
Robert,
One day in January of 1964, as the System/360 was tearing along for an April 7 whole-family announcement, John Haanstra, brilliant engineer and great manager, President of the General Products Division (who had been opposed to the S/360 plan all along so far as the 1401 family went), sprung a surprise. He convened a multi-day meeting of the Group executives in White Plains and pitched the (quietly developed) 1401S as an alternate product plan for the lower part of the market, instead of the S/360 Models 20 and 30. These latter were in his product responsibility, but he had grudgingly let them be developed in his labs.
The 1401S was to be 6x the 1401, at least upward compatible from the 1401, and priced the same as the 1401. The argument was indeed based on Honeywell's Liberator, which was, I believe, more than software—I recall it as having a hardware-assist to help emulation of the 1401. (Centefelli's recollection is probably more accurate than mine.) Haanstra's argument was that the incompatible S/360 Models 20 and 30 would essentially give away the 1401 market to Honeywell, whereas the 1401S, although it would impact 1401 rental revenue, would make a lot of money. It was a potent argument indeed, both in substance and in timing, because the Liberator was the panic du jour for the company brass.
This proposed change would have been a death blow for the S/360 family. The 1401 market was more than half of our total forecast in terms of number of machines, and perhaps half in $. Spreading the software cost over half the revenue would have ruined our prices. Moreover, the 1401S would have taken a big share of the Solid Logic Technology chip production, which turned out the be the limiting factor on delivery schedules.
We had the DSD-invented emulator technology rolling vigorously for the 7090 on the Model 60. So Evans and I immediately thought that afternoon of seeing what we could do for a 1401 emulator. I called Poughkeepsie and Endicott and set up the plan.
William V. (Bill) Wright and Gerald (Gerry) Ottoway were my two-person technical cavalry team, genius computer hardware and software designers that I sent to wherever the battle was thickest. They had helped turned around the Böblingen lab technically from a 1401-ish little machine to the Model 20, after we had won that political battle, so they were intimately familiar with 1401-ish dataflows and S/360-ish microcode.
They and I severally flew to Endicott that night, where we joined the chief architect of the Model 30, William (Bill) Hanf. The three of them designed and microcoded all night, while I listened, approved sub-decisions, cheered, and kept fetching the coffee. By dawn we had a design that required one very minor modification in Model 30 dataflow, and we had actual microcode for the instruction-fetch-decode loop and all the most common operations. We had timed it on 1401 instruction mixes and knew that it would run 4x the 1401, at least. Yes, I was elated!
I caught the early morning flight from Endicott back to White Plains and presented these new results at the second day of the meeting. What our new plan offered was 1401 compatibility and an easy customer transition into S/360 and hence the growth and future mainstream. Needless to say, this new development was as startling as Haanstra's assault on the official company product plan had been. The meeting adjourned, to come back on the third day. Lots of discussions went on in White Plains that night.
When we convened the next morning, Haanstra wasn't there. He had sent Ty Marcy, his Division Manager of Engineering, to represent GPD. I knew then we had won. What had happened overnight was that John Opel, then President of the Data Processing Division (field marketing and sales force), decided that our plan represented the right way forward for the company. His reasoned and influential voice convinced the top brass. From then on, the company really united in making S/360 happen, and we announced on April 7 as planned. A little while later, Haanstra left to become head of computers for GE.
Of course, the emulator microcode generated that night had to be checked, expanded to cover all operations, and productized.
Fred
On Mar 18, 2009, at 10:33 PM, Robert B Garner wrote:
Fred,
Thanks for your reply/question on 1410 OS.
Re: my earlier 1401<-->360 questions, if it's OK with you, I'd like to ask them one at a time (there are 3 ;-):
1) My reading of the history is that the H200 Liberator software* startled IBM management and market planners into realizing that, as the 1400 series was end-of-lifing, that (only then) you guys needed an engineering plan and demonstration that the 1401 could be efficiently emulated on the low-end 360s. Is that accurate history? Or was the plan all along, before the H200 came on the scene, to emulate a 1401 (and 1410?) on the low-end 360s (model 30)? Or perhaps the (unexpected?) appearance of the H200 just accelerated the need to demonstrate the expected 1401 emulation performance (to help kill the 1401S)?
When you were at the CHM for the Stretch event, you described to me the moment when three of your team members determined they could effectively emulate the 1401 in the Model 30 microstore. What were their names again and what had been your elated reaction? Can you describe the 1401 emulation effort? (I have the CACM paper on 1401 emulation on 360, but it's not very revealing...)
Thanks for helping to capture this interesting history,
- Robert
* Created by an ex-member of the 1400 Endicott software team,
as shared by Bob Cenfetelli**:
** Bob Cenfetelli: "I was one of the original software
developers on the 1400 series in Endicott. I wrote some of the
Disk utilities for the 1405, the author of the Control Sequential
file organization and also contributed to one of the Sort packages."
|
eighth most recent
|
----- Forwarded by Robert B Garner/Almaden/IBM on 03/18/2009 07:03 PM -----
Robert B Garner/Almaden/IBM 01/06/2009 07:29 PM To Fred Brooks/Alpharetta/Contr/IBM cc Robert B Garner/Almaden/IBM@IBMUS Subject Buzzing (was Fw: More Re: IBM 1401 family compatibility, S/360 emulation, Xerox STAR, SPARC, etc Fred, Any luck finding any time to address my 1401 / 360 related questions (below)? I hope all is going well on your new book. And Happy new year! - Robert
|
nineth most recent
|
----- Forwarded by Robert B Garner/Almaden/IBM on 01/06/2009 07:26 PM -----
Robert B Garner/Almaden/IBM 11/25/2008 05:34 PM
To
Fred Brooks
Fred,
Thanks for taking on my questions about 1401-compatibility in 360 land (when you're able to find the time!)
This is much appreciated and valuable for the 1401 project and the Computer History Museum.
(I plan to write a more detailed paper about the 1401 history next year.)
Adding a bit to question #2 below (about impact of H-200 on 360 design): I assume the original efforts to get control store working in NPL models was driven by the need to emulate 7000-series? Was there no 1401 support plan (in low-end models) until the H-200 announcement?
And any more anecdotes about the bake-off between the 101H and 1401-S projects? pgs. 162-163 in Pugh et al sound like a terrifying fight, with engineers caught in the middle on both sides... Where you at the Feb/64 meeting where 1401-S was canceled? Do you recall anything more from it?
In Chuck Branscomb's recent history on 1401 program, here:
Chuck wrote the following. Any feedback on this, 45 years later! ;-)
My recollection is that only the Model 65 of the 360 program had serious work underway on emulation prior to the announcement of the Honeywell 200 Liberator. Emulation using read-only store became a major thrust on several models of the 360 under development, and I believe frankly that the Honeywell 200 announcement turned out to be a significant plus for the 360 line because without good fast emulators, 360 would have had a very difficult time. The problems with the 360 operating systems only emphasized the importance of very good emulators of the then current product line.
It turns out it would probably have been wise to do both—some version of the 1401S, as well as, all of the models of the 360 line. The reason I note this is that while the 360 was very successful, it was mostly in equipment rental range above that of the 1401 program. As a matter of fact, in April 1964, when the 360 was announced, IBM had 87 percent of the business for systems in the rental range of $2,500 per month to $10,000 per month. Five years later, in 1969, IBM only had 47 percent of the business for equipment in the rental range of $2,500 to $10,000 a month. This led Frank Cary to start the General Systems Division with the focus on the low end of the line, and it became the only computer division in IBM to be integrated with its own development, manufacturing, marketing, and service. By the way, GSD was very successful in the low end of the business line with the System 34, System 36, and System 38—which later with enhancements became the AS/400. The division was less successful with its Series 1 entry into the mini-computer business, but did develop the IBM PC shortly before the division was integrated back into IBM.
Also, can you comment on which aspects that you dislike most about the 1401's ISA? Word marks, serial nature, BCD, etc ?
Chuck as remarked that some people "didn't even consider the 1401 to be a computer."
(I agree it can be viewed as an "embedded" IO controller, well tuned to it's particular peripherals.)
- Robert
|