🚀 go-pugleaf

In article <3050@blake.acs.washington.edu>, mrc@Tomobiki-Cho.CAC.Washington.EDU
(Mark Crispin) writes:

>Back in days long by, people would actually *do work* in a power-of-2-based
>number counting system.  You would not believe how much easier it is to do
>arithmetic in octal instead of hex -- not to mention translating between
>octal and the values displayed in the lights or that you key in the switches!

This is either missing a smiley or is the dumbest thing I have ever read
on comp.arch.  Listen carefully, bucko:  hexadecimal is base 16.  Last
time I looked into the matter, 16 was a power of two, and I have not had
much trouble translating it into binary, if you know what I mean and I
doubt you do.

(*flame off*)

[maybe he thinks hex is decimal??]

I used octal back when I was working on those good ol' Honeywell
mainframes.  Octal is a very sensible radix for a 36-bit processor
that has lots of 18-bit and 6-bit fields, and uses either 6-bit or
9-bit characters.  Unfortunately, I gather that Honeywell (and 
therefore Prime, later) went ahead and used octal on their 16-bit
processors.  This is like putting socks on a rooster.  Octal is
incredibly inconvenient when trying to do something like figure out
what character is in the upper half of a 16-bit quantity.

I know Bill Davidsen is a Honeywell veteran, and I see Alex Colvin
posting every so often [Hi, Alex!  when are you going to escape grad
school?]  Anyone else?  I admit that the Honeywell 600/6000/DPS lines
had some real drawbacks, e.g. single-accumulator, but I liked
programmming them, and the extended instruction set (EIS) was a wild
thing to work in once you got the hang of it.  Being a systems
programmer on the Dartmouth Time-Sharing System was really the life
at times...

Honeywells were basically IBM ripoffs with a special Gray-to-binary
instruction added so they could work on radars on the DEW line.
They had some interesting features; not only did they have an
execute (XEC) instruction that would execute the instruction at the
effective address, they had execute double (XED) that would execute
the two instructions starting at the effective address.  Since the
second of the pair could also be an XED, you could set up a chain
of these things.  Such chains were not interruptable, but this was
handled by starting a timer when the processor entered an inhibited
state (you could also do this by setting bit 28 in each instruction)
and if the timer expired, the processor faulted.  Such a fault could
occur in the middle of an instruction, making the process non-
restartable.

The other feature I've not seen elsewhere was the repeat instruction.
This had the effect of repeatedly executing the instruction following
the repeat (RPT), or the two instructions following (RPD) up to 256
times.  You could specify condition code settings that would end
the iteration before the count ran out.  There was even repeat-link,
which would follow a linked list.  They were very fast when it was
all done in hardware, but now the machines are microcoded and it's
faster (as I hear it) to get rid of the RPT and do the iteration
yourself.  Sigh.  All that tuning for nothing.

    -- David Wright, Stellar Computer, Inc
       wright@stellar.stellar.com

  "Whatever it is, just tell them 'no'.  I'll fix it." 
     'The Man Who Sold the Moon', Robert A. Heinlein