From: alderson@elaine46.Stanford.EDU (Rich Alderson)
Subject: Re: octal to decimal converter?
Originator: alderson@leland.Stanford.EDU
Reply-To: alderson@elaine46.Stanford.EDU (Rich Alderson)
Organization: Stanford University Academic Information Resources
Date: Wed, 16 Dec 92 23:50:28 GMT

In article <D03PVB3w165w@mertwig.uucp>, daniel@mertwig (Daniel Drucker) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>>In article <oDaLVB1w165w@mertwig.uucp> xyzzy%mertwig@uunet.uu.net  (Daniel Dr
>>>I was just reading about the (octal?) to decimal converter that the hackers 
>>>MIT in the (60s or 50s?) were writing, and how they tried to do it with
>>>fewer and fewer instructions. I'm wondering if anyone has the listing
>>>(it was PDP-1 assembly I think, or maybe TX-0?) of it, which turned out to b
>>>48 lines.
>>
>>That seems a bit long, assuming it's PDP-8 code; probably too many bits since
>>the PDP-1 was 18 bits, not 12.  When you're trying to write tight code you
>>have to eliminate all extra bits!
>
>Well, you'd know more than me; I read it in Steven Levy's 'Hackers', you were
>probably there...
>
>I would like more info on this subject though...feel free to mail me if you
>don't think it's appropriate here.

It should be a lot less than 48 lines, even in PDP-1 code.

And besides, as anyone who has read _Hackers_ ought to remember, the AI Lab
hackers didn't use decimal anyway, because octal was what the machine expected.

(In the EMACS manual for Tops-20, there were interesting tidbits at the back.
One was the description of how the 9-bit EMACS/TECO character set was mapped
onto the 14-bit TV character set.  The bits kept adding up to 12, for me; it
was a while before I realized that it might be 9(decimal), but that it was
14(octal) friends... :)

On a related note:  We had an RA81 fail (I know, I know, the surprise is that
the others didn't) at LOTS.  It was the middle pack of a three-pack PS:, so it
was going to be a problem to recover as much data as possible.  Or so we
thought.

There was a program, written at Stanford in the deeps of time, that would do
raw disk I/O so that a properly-educated person could re-build smashed directo-
ries, and similarly wizardly stuff.  Because it made use of the DSKOP JSYS
("system call", "SVC"), it was cleverly called DSKOP.  The director of LOTS,
Ralph Gorin, was the author of same.  He sat down at a Z19 in the public area,
pulled up the source of the program, and began to hack.

The RA81 had a different physical layout from the others, affecting the calcu-
lation of such things as the location of the home block ("disk label" for you
non-20 types), so Ralph parameterized that.  In addition, he made the program
announce whether the filesystem for which it was built was DEC-standard or
Stanford-extended.  (DEC's version would only build a one-pack structure on
RP07 or RA81 drives--not enough address bits.  Stanford upped it to where up to
4 such drives could be in a single filesystem.)

He proceeded to write a generalized pack-to-pack copy routine, one which would
work on any drive supported by the operating system.  (This was easier than
modifying the RALPH program, which worked for RP06's.)  He decided that it
needed to respond to an interrupt character to tell the user how far along it
was in its job, printing out disk addresses and such.  The point to all this:

    He needed to provide an octal output routine, *so he entered one from
    memory*, short, highly bummed, and working the first time out.

Compiled it, fired it up, and took the system manager and me (the system
programmer at the time) out to dinner.

Total time to implement was about 45 minutes.
-- 
Rich Alderson   'I wish life was not so short,' he thought.  'Languages take
                such a time, and so do all the things one wants to know about.'
                                                        --J. R. R. Tolkien,
alderson@leland.stanford.edu                              _The Lost Road_
Xref: sparky alt.folklore.computers:17987 alt.folklore.urban:31395