Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!uc!noc.MR.NET!ns!ddb From: ddb@ns.network.com (David Dyer-Bennet) Newsgroups: comp.arch Subject: Re: Odd word size? Word size? Word? Definitely Odd. Message-ID: <1990Oct8.220412.25532@ns.network.com> Date: 8 Oct 90 22:04:12 GMT References: <270CB430.21156@ics.uci.edu> Organization: Terrabit Software Lines: 81 In article <270CB430.21156@ics.uci.edu> baxter@zola.ics.uci.edu (Ira Baxter) writes: :It has been a long time since I touched an IBM 1620 or 1401, and my :memory is a bit fuzzy on the details. Real oldtimers, feel free to :correct the fine details. The 1401 was quite similar in style to the 1620, :so I'll skip describing it. I can't possibly be a real oldtimer, I didn't start in the field until 1968, but those happen to be my first two machines, and I still seem to remember things about them. First off, the 1401 isn't particularly similar to the 1620. The 1620 is decimal digit oriented, whereas the 1401 was character oriented. The instructions lengths were different, and the 1620 used fixed length instructions whereas I'm nearly certain the 1401 had variable length. :If I remember right, these machines violate not only the notion :of power of two word sizes, but even the notion of word size. : :The IBM 1620 had a 5-bit "digit", which could represent, using 4 bits, :a decimal digit or some special codes, one of which was called a :record mark. The 5th bit was called a "mark" bit. Addressing :granularity was to the "digit" level. Actually it was called a "flag". A "record mark" was a character code (2 digits) relevant to some (few) character string instructions. The binary displays on the console showed a memory location as lights for "CF8421"; the C was a "check" bit (parity). You'll note that there were invalid combinations (anything adding to more than 9). :It was :fun to "clear core" (by MOVing a single digit number without mark bit :to its own address+1) and then enter an add-to-self instruction; this :put the machine into an infinite loop adding the digits of the :enormous number defined by the complete absence of mark bits. Reset, Insert, "260000800009", Release, Start (or just use the handy "R-S" key on the console typewriter). This is how most sessions began. The infinite loop wasn't because of addition taking forever (it's a move instruction), but simply because both source and destination addresses wrapped around at the same place. You could also do it with a move immediate instruction, as "160001000000", and there was a version using the transmit record instruction that was special because it moved through memory in the other direction (transmit record going left to right instead of right to left). This is weird; I remember instruction names, and I remember numeric opcodes, but I DON'T remember assembler mnemonics. :I think characters were formed by taking pairs :of digits. Yep. :Earlier 1620s had a multiply instruction which worked by looking :up multipler/multiplicand digit pairs in the multiplication table :in lower memory. This table had to be loaded correctly before :you used multiply. There are apocryphal stories of folk loading :the table in such a way that multiplies worked in octal rather :than the standard decimal. Never mind multiplication; ADDITION also worked this way. And I'm not aware of any vintage 1620 that DIDN'T use tables. There was a hardware write protect on the table space in later models, though, controlled by a switch on the console. At Carleton College, the Load and Go Plot program (written by Mark Bramhall) used deliberate modifications of the tables to help it rotate its fonts 90 degrees for portrait format presentation. :I suspect this machine would put a "C" programmer into a rubber room. Hmmm. Pick an "int" of 5 digits and you have sizeof(pointer) == sizeof(int). You could have a long of 10 or 15 digits, and a char of 2. Except that all lengths have to be in units of sizeof(char), eh? Hmmm. -- David Dyer-Bennet, ddb@terrabit.fidonet.org or ddb@network.com or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300