[comp.arch] Odd word size? Word size? Word? Definitely Odd.

baxter@zola.ics.uci.edu (Ira Baxter) (10/05/90)

There has been recent query on machines with word sizes that
were not a power of two, related to algorithms that used binary addressing.

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.

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.

There were no registers (take THAT! mr. optimal register allocator)
save some peculiar regions in lower memory that acted like index
registers; all operations were memory to memory.

One defined an arithmetic data
object by using specifying the (decimal!!) address of the least
significant digit.  The arithmetic data object extended from there
thru more significant digits (at successively lower addresses) until a
digit was found with the mark bit set.  One defined a numeric field at
runtime by applying a "SETMARK" instruction at addresses representing
Most Significant Digits of areas to be used as numbers, although I
think the assembler would arrange this for you automatically.  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.

String-class objects worked the opposite way; the lowest address digit
was specified, and the object ended when a digit containing a record
mark code was found.  I think characters were formed by taking pairs
of digits.  Instructions were 12 digits, a 2 digit opcode, and 2,
5-digit addresses; I think the MSD of the opcode had to have the mark bit set.
I forget precisely what happened when you gave an
odd-sized string to instructions that printed strings on the console,
printer or card punch (Who needs PRINTF?  The hardware did it
directly!), but the 1620 had lots of entertaining ways of aborting
your program, including the infamous "CHECK" light, which froze the
machine whenever a malformed instruction, or numeric operand
(containing a record mark) was encountered.

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.

I don't remember any boolean operations such as AND or XOR.
They'd be a bit out place in a decimal machine, certainly out
of character.

It was amazing easy to enter raw machine code.  You could
literally type it in on the console terminal or enter via card
punch.  I spent many enjoyable hours doing this (forgive me,
this was the machine on which I learned assembly.  The 360
was total surprise!).

Anyway, to summarize: You can't talk about word size when you don't
have the notion of word.  If you insist on a digit as "word size", I
can't imagine an odder size than 5 bits.  Addresses were all 5 digits
and decimal.

I don't think I'd try to run an algorithm on this machine that
depended fundamentally on powers of two related to word size.

I suspect this machine would put a "C" programmer into a rubber room.

--
Ira Baxter

jthomas@nmsu.edu (James Thomas) (10/09/90)

In article <270CB430.21156@ics.uci.edu> baxter@zola.ics.uci.edu (Ira Baxter) writes:

ira> There has been recent query on machines with word sizes that
ira> were not a power of two, related to algorithms that used binary addressing.

ira> It has been a long time since I touched an IBM 1620 or 1401, and my
ira> memory is a bit fuzzy on the details.

Well, yeah :-)

ira>                                        Real oldtimers, feel free to
ira> correct the fine details.

Gee, I wonder if I qualify?  I'll jump in anyway ::-{}

ira>                            The 1401 was quite similar in style to the 1620,
ira> so I'll skip describing it.

Well, actually you mixed them up a bit ;-)

ira> ...  The 5th bit was called a "mark" bit.

It was the seventh (or is it 0th?  No, they were definitely little endian
:-) bit on the 1401/1460/1410/7010 that was the "word mark".  The 5th bit
on the 1620 was a "flag" bit.

ira> ...
ira> There were no registers (take THAT! mr. optimal register allocator)
ira> save some peculiar regions in lower memory that acted like index
ira> registers; all operations were memory to memory.

Well, the index registers were on the 14xx, three optional in the 1401 and
five on the 1410.  Or did the 1620-II or 1710 have index registers too?

ira> ...  One defined a numeric field at
ira> runtime by applying a "SETMARK" instruction at addresses representing
ira> Most Significant Digits of areas to be used as numbers, although I
ira> think the assembler would arrange this for you automatically.

Well, it was an "SF" ("Set Flag") on the 1620 and an "SW" ("Set Wordmark")
on the 14xx.  Yes, the assembler did it on the 1620, but the loader (for
cards, not tape or disk) had to do same on the 14xx.

ira> ..  Instructions were 12 digits, a 2 digit opcode, and 2,
ira> 5-digit addresses; I think the MSD of the opcode had to have the mark
ira> bit set.

No, there were no flags needed for defining the instructions.  Immediate
instructions needed flags for their immediate values.  The flag also served
as an indirect address flag "over" the low order digit of an address.

ira> I forget precisely what happened when you gave an
ira> odd-sized string to instructions that printed strings on the console,

Nothing for odd-sized, but CHECK STOP for odd addresses.

ira> ...
ira> Earlier 1620s had a multiply instruction which worked by looking
ira> up multipler/multiplicand digit pairs in the multiplication table
ira> in lower memory.   This table had to be loaded correctly before
ira> you used multiply.  There are apocryphal stories of folk loading
ira> the table in such a way that multiplies worked in octal rather
ira> than the standard decimal.

Ah, you must have used a model II :-)  The model I had add and multiply
tables in memory.  It was easy to do binary or octal adds, much harder to
do multiplies.  I don't think the stories are "apocryphal".  I did it :-)

ira> I don't remember any boolean operations such as AND or XOR.
ira> They'd be a bit out place in a decimal machine, certainly out
ira> of character.

No smiley here? :-)

ira> I suspect this machine would put a "C" programmer into a rubber room.

Hmmmm, C on a 1620???  Just a few portability problems with char's that
took two addresses :-) :-) ;-)

Jim Thomas, aka Nothead, creator of the NOTHED assembler for the 1620 :-)

ddb@ns.network.com (David Dyer-Bennet) (10/09/90)

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