return to Origins of Architecture and Design of the IBM 1401

Monday Morning Quarterbacking the IBM 1401 Design,
50 year later ;-))


Goal of this future web page

What me second guess some designer ??? ;-))
of an outstandingly/wildly successful product ??? ;-))

I think this "Monday Morning Quarterbacking" web page can contain several points,

that may yield interesting questions and answers.

Your questions, comments, answers are requested :-))

There are many interesting possible topics. A few are:

a) Project goal ??
b) Lack of I/O and compute concurrency
c) That wonderful krazy chain printer
d) Only 3 digits of address space


a) Project goal ??

from Fran Underwood

Apparently, because I didn't design the full 1401 architecture at the beginning (I, and others, failed to realize the full scope of the market), it was necessary to continually modify the architecture to adapt to the changing requirements.

Consequently, some of the changes were awkward.

I don't know if there is a lesson to be learned here or not. I'm pretty sure that if we had waited for ALL market requirements to be included in the design before release to manufacturing, there never would have been a 1401.


from Robert Garner

No one can really be sufficiently "visionary" of customer/market requirements! But the pressure you, marketing, and management undoubtedly felt to get everyone's favorite feature in ("kitchen sinking" as we called it) must have been relentless, and I suspect, supported the adoption of microstore in the S/360. IBM's core values were/are to kept customer needs at the forefront. With microcode, certain new features could be easily added and some bugs repaired, very late in the productization process and clearly even into the field. (IBM even perfected "just-in-time", ion-beam metallization of chips for a while to allow for late chip features/bug fixes.)

But like all over indulgence, the microstore S/360's cemented the "inefficiency" foundation for RISC to emerge later (beginning with IBM's John Cocke's 801 project and new compilers in early 70's), which is the wave I rode at Sun Microsystems, as architect of SPARC. Ironically, all the early computers (before 70's) had RISC'ish, simple instruction sets, but just not enough registers, enough main memory, memory management units, etc..

I like to think of the 1401 as an "appliance" in the sense that it was explicitly designed to control a particular class of peripherals (1403, 729s, 1402, et al) at a lowest cost practicable. Such "sweet spot" machines can be very successful, as demonstrated by the 1401's success. Future enhancement models then expand on the initial success (1440, 1460 in this case).

I wonder if the S/360 perhaps went "up scale" just a tad too far, when what the market really (still) wanted was lower-cost computers? Minicomputers were that next wave, then "hobby" PC's :-), then RISCs, now hand-helds. ;-)

> I don't remember any of this stuff [the 50's memos]

Likewise, I don't recall my own emails/memos from the late 70's when I was designing the Xerox STAR 8010 professional workstation.

Thanks for sharing your thoughts and stories!

- Robert


from John Pokoski

Re Fran's remembering, it is human nature I guess. I noticed that I remembered fairly well my early multiply/divide memos and didn't remember at all the process overlap memos two years later. I think that is because the early M/D stuff was my first engineering work and was really exciting to me. It probably made a deeper imprint on my memory and I may have even thought about it over the years thus providing memory refresh. Besides, I thought M/D was precise and neat. On the other hand, after a couple of years, the excitement of the 1401 and a new job dulled. And process overlap was relatively messy.

I suspect Fran had a similar situation. I can only imagine how exciting it was to be the singular architect of a new machine. Especially such a revolutionary one. I read his early design studies and was amazed at their clarity and completeness, right down to the practical sample programs he wrote and the memory partitioning. I had to do similar things in grad school in computer architecture courses and later required students to do so in courses I taught. However, there was never the amount of detail that Fran produced. Plus it was only a game while Fran's was the real thing. I imagine that after the first prototype was pretty much running, and the emphasis was more on minor modifications and production details, his excitement decreased and thus the memories were not retained. I also imagine that since he has saved his original design memos that he has looked at them since, thus providing memory refresh.

Unfortunately, Fran's response sounds almost apologetic that the machine hadn't been designed to perfection on the first whack. That's outlandish. I considered Fran a visionary, close to a genius, when I observed him fifty years ago. After reading his early design memos last week, I was even more impressed. Fifty years ago I was too green to realize the uniqueness of the editing scheme, add to memory, etc. and how this related to market needs re replacing unit record stuff. Few people can (or will) carry a project through from the high level ideas to the nitty-gritty details. Besides, there is no way that one person can know everything important to a market, and as more people saw the plans they apparently made useful suggestions.

Incidentally, I chuckled at Fran's distaste of plug boards expressed in the early memos. I recall in later days when some sort of peripheral (I forget what it was) was to be interfaced to the 1401, and Fran noticed that the perpheral used a plug board, he almost became apoplectic. It would contaminate the system!

John


   Most projects (in my experience) start with  a charter, or set of guide lines,
        and/or considerable dialog with proposed customer(s),
        if not a signed contract to be implemented.
     Marketing usually has some inputs,
          which Engineering of course snickers at -
     But there is usually a goal more detailed than
          "make something that will make lots of money"

     I don't remember any mention of management goals for the project,
          other than a manufacturing cost or rental price mentioned by Shel Jacobs
          last June -  http://ed-thelen.org/1401Project/Sched2008June.html#All
              http://ed-thelen.org/1401Project/FranUnderwoodJune2008.html

     So - what were the goals, targets, guide lines, ... of the "SPACE" project?
          other than a cost target?
              and something appealing enough to get IBM to produce it  ;-))



b) Lack of I/O and compute concurrency
   Considerable has been made of the lack of I/O and compute
        concurrency in the original 1401.
     OK - we all have used DMA (Direct Memory Access) for years -
           a relatively simple, inexpensive method of concurrency -
               (well, until the modern cache consistency nightmares)
          The I/O cycle steals memory cycles from the CPU.

      Searching through 
         "A Survey of Domestic Electronic Digital Computing Systems", 
                  Ballistic Research Lab, December 1955 Report No. 971 
              http://www.ed-thelen.org/comp-hist/BRL.html
        many/most machines  before 1956 seemed to be able to 
             compute concurrently with I/O 
        Included in a search for "concurrent" were DYSEAC, Ferranti Mark 1,
        IBM 702, 704 ("partially"), 650 ("partially"), NORC, Whirlwind, ...

        So, Jim Ingram, Fran Underwood and group likely heard of 
                concurrent compute and I/O,            
             - say in the form of DMA, but didn't include it in the original 1401.
         This could have been costed out of the machine, extra circuitry?
             or not included for reasons of user operational complexity ?
      
          HOWEVER !!
          One of the joys of using a 1401 is its user operational simplicity !!
              Say there is a card read check.
              a) There is a card read instruction in the Instruction "Register"
                    and the card causing the check is easy to locate !!
              b) The operator can easily take correct corrective action,
                    say reproduce a defective card and place it back in the card reader
                  AND CONTUNUE TO RUN THE JOB FROM THAT POINT !!!.
          Such is not the case were you are using double buffering software,
            and DMA hardware 
              - locating the card causing the check is definitely "more interesting" 
              - and recovery from such a situation
                  had better be programmed by the software writer - hardly ever !!
          You likely tried to find the defective card and had to restart the run.

 
c) That wonderful krazy chain printer
   And how did that ridiculously difficult print method of 
          a chain of print slugs running horizontally across the ribbon and paper 
       get accepted as the printer for the 1401 system ??
            - and become the most admired print technology for the next 20 years?

       Of all the silly ideas -
         - any competent person could safely assure management 
              - "that printing technique has too many weak links" !!!     
       But work it did !!   To the great admiration of the printing world  !!
           Any print displacement due to time of flight of the hammers,
               a tedious adjustment that could drift due to many reasons -
           was horizontal and hard to detect
           On the "industry standard" drum printers,
               time of flight errors caused vertical dispersion,
           really annoying and "un-professional".

       I'd REALLY like to hear the 1403 printer story -



d) Only 3 digits of address space
   One of the joys of a decimal machine such as the 1401 is that addresses are also
      in decimal.    
   No need for messy decimal to binary conversion when hand coding small quick programs.

   HOWEVER - the range of that joy is limited from memory address 000 to 999 
      after that, life gets even more confusing than binary addition -
    the Dark Side, addressing above 999
   A 4 digit address space would have made hand hacking much simpler -
      (Assemblers and other language processors took care of memory addressing
          when you used them.)
   Quiry, do you wish you would have used more digits in addressing?




  The above is a start for a "Monday Morning Quarterbacking" dialog  ;-))




Please send contributions, suggestions, complaints, ... to Ed@Ed-Thelen.org


go back to Origins of Architecture and Design of the IBM 1401