return to main 1401 Restoration Page

(The IBM 1401 has)
Meaningful 1 Character Op-Codes

E-mails early February 2011

Table of Contents:


Background
Digital computers are in general rather user unfriendly machines
  • They talk binary - you and I talk decimal
  • The codes that tell the machine what to do next (the "Op-Codes) are almost always in Octal or Hex. If you don't know what these are, consider yourself one of the unwashed - and go back to the cave or bar.
  • The Op-Codes make no sense at all - even the architect has to memorize them.

EXCEPT the IBM 1401

Fran Underwood, 'chief' (only ;-) architect, made decisions such as op-codes -
He wanted to make a simple, understandable machine so that people who have been "programming" unit record equipment

  • planning data flow
  • wiring unit record equipment plug-boards
  • "pushing cards"
    for years could understand what the 1401 was being instructed to do with out constantly referring to a cheat sheet.
  • maybe they could even also "program" this new machine (1401) :-))
    Every Op-Code is a printable character (no illegal or blank)

    This is one of the joys of working with a 1401 -
    You can look at memory, or a printed memory dump, and understand op-codes :-))


    In an e-mail to Fran Underwood, Robert Garner commented
    "Was it "fun" or frustrating selecting the one character opcodes?
    A for Add, B for branch, M for move are obvious, but I can't see the logic in some:
    ? for zero and add, ! for zero and subtract, Q for store A reg, lozenge for clear word mark.
    Where you torn on some of the assignments?"

    Fran Underwood responded
    Well, there were a limited set of printable characters to choose from. I started with what I thought were the most important, most used operations and assigned the most mnemonic characters to them. After those were used up, I tried to do the best I could, but the effort proved to be too much and I had to resort to 'eeny-meenee-minee-moe'. The Op codes 1-9 makes sense to me, since 1, 2, 4 could combine for the various combinations of Read, Print and Punch. I'd be interested in hearing a better assignment of codes. With the advent of HHLs. the assignment became moot, though still useful when trouble-shooting.

    IBM 1401 OpCodes, Van Snyder's remarks
    
     , is natural for word mark.
     lozenge, the empty box, is natural for clear word mark.
     A is natural for add.
     B is natural for branch.
     C is natural for compare.
     D is natural for move digit.
     E is natural for edit.
     F is natural for forms control.
     J is natural for jump (1410).
     L is natural for load.
     M is natural for move.
     N is natural for NOP.
     S is natural for subtract.
     T is natural for translate (1460).
     Z is natural for move and suppress zeroes.
    
     ? is CBA82, or +0, natural for zero and add.
     ! is B82, or -0, natural for zero and subtract.
       (the Fortran II floating-point package used these to
       remember signs).
    
     H for store B register?
     K for select stacker (and many other arcane things)?
     P for move record?
     Q for store A register?
     V for branch if word mark or zone?
     W for branch bit equal?
     X for move and insert zeros?
     Y for move zone?
     1-7 for unit-record I/O?
     8 for start read feed?
     9 for start punch feed?
    

    Jud McCarthy, who was there :-)), comments
    Robert: Just a fun comment. When we were developing the 1401, we workers called the lozenge "the sucked in box" as it was a square with all four sides sucked in. As mentioned ..., it was used to clear word marks. I remember using it when putting together test code for the Print Edit feature, designed by Dick Bennet, with direction from Fran. ---- Jud

    Van Snyder comments further
    I agree with Fran. I think I arrived at the same conclusions Fran did, concerning the obvious ones. Fran invented them, I just observed the logic behind it. I should have been less laconic about the ones for which I just wrote question marks. What I had in mind was "What else could be done?"
    
    
    H for store B register?  - B was already taken.
    K for select stacker (and many other arcane things)? 
           - S was already taken.
    P for move record?  M was already taken.  
           - Maybe R would have been better?
    Q for store A register?  A was already taken.
    V for branch if word mark or zone?  
           - B and Z were already taken.
    W for branch bit equal?  B was already taken.
    X for move and insert zeros?  Z was already taken.  
           - Maybe I would have been better?
    Y for move zone?  Z was already taken.
    1-7 for unit-record I/O?  
            - Fran has explained the logic behind this.
    8 for start read feed?  This is unit record I/O, too.
    9 for start punch feed?  This is unit record I/O, too.
    
    I left out:
    % for divide is obvious.
    @ for multiply is semi-obvious: 7 @ 9 cents each is 63 cents.
    / is reasonable for clear storage (got a better idea?)
    . for halt is obvious.
    
    Summary
    38 op codes (including J in 1410 and T in 1460) using printing characters
    12 printing characters not used: G, I, O, R, U, 0 (zero), &, $, *, -, #, | (record mark).
    12 nonprinting codes with 5-8, 6-8, 7-8 and either 12, 11, 0 or no zone not used.
    blank not used

    Maybe better ideas would have been
    
    & for add (prints as + on the H chain)
    - for subtract
    
    freeing up:
    A for store A address register
    S for select stacker.
    
    R for move record
    W for branch if word mark or zone
    I for move and insert zeroes
    Maybe then X for branch bit equal?
    

    But this is all Monday-morning quarterbacking. Fran did a superb job.

    Van

    A user/abuser comes on line ;-))
    from
    LaFarr Stuart
    Thanks. The logic behind the choice of 1401 op codes is interesting. And, at least on 4K 1401's virtually all program debugging was done by looking at memory dumps taken at various stages of the program running. Knowing the op codes was essential. Every 1401 programmer should be grateful for Fran's work.

    Another great feature was the hardware dump. It printed dumps in line pairs:
    The first was the characters in memory,
    and under it was a line of 1's and spaces. The 1's were effectively the word marks.

    You would hardware dump a couple lines, and then run a dump program which would dump the rest of memory in the two line form.

    Early in the 1401 days there were lots of 4K card only 1401's. I believe this is the configuration that got the 1401 market going; then as users kept doing bigger jobs, they upgraded to 16K and magnetic tape. Because the printer and card equipment on the 1401 were very good, another market opened up: I/O processing for larger scientific machines such as the IBM 7090's. Because of IBM's superior tape drives these machines turned out to be great for sorting records--I suspect there were many 1401's that did little besides sorting, printing, reading & punching cards.

    It was not easy for the 360's to do all this. I think this is why the 360 had a bumpy start. Many felt they would rather "Fight than Switch" For technical reasons 32 bits was poor, when compared to 36 bits for single precision Floating Point of the old 7094's. GE and DEC stayed with 36 bit architecture, but ultimately 8-bit characters (with both upper & lower case) won over 36-bit Floating point and 6-bit (Upper case only) characters.

    Cheers,, LaFarr
    from Quartzsite

    from Charles Branscomb - 1401 Project Manager
    I don’t remember the actual words Poky [Poughkeepsie, N.Y. design center of IBM 701, ... 7090, 702, 705, 7080, & more] (and other “computer people) said about the 1401 but they were dismissive, knew the 1401 was going nowhere and they then ignored us. That was fine with me since I did not want to waste time dealing with their views. I haven’t mentioned one other thing that shows what the Poky people thought of the Endicott lab. In about 1956 Poky leadership pursued a determined effort with headquarters to get IBM to transfer ALL electronic development from Endicott to Poky and make Endicott a mechanical design lab. Fortunately, lab director Jim Troy was a strong leader, adamantly opposed to such a move, and was able to convince the company that it was foolish.

    You have heard me say often that having a known “target”, the punched card installations, was extremely important to us. Fran had been immersed in punched card world for some time and I had been an operator, plugboard wirer, and manager in an installation serving the 36,000 GI’s in Korea. This background allowed Fran to really focus his architecture and allowed us to establish objectives that, if they were met, would clearly meet the customer needs in this area. The next step was Shel coming on board, doing a lot of work on skills in these installations, helping make sure the 1401 was as simple as possible and getting the required training program set for our field people as well as customer people. As you know, he also had to “train” the forecasters.

    I personally feel that the 1401 was easily the most “user friendly” system IBM produced until well into the 1970’s. My bias shows up when I tell you those systems were developed in the General Systems Division – the System 34 probably being the leader followed by System 38.

    Chuck