What does LETTER. do in LISTRD in FAP from 196x? | Hacker News Reader

What does LETTER. do in LISTRD in FAP from 196x?

drive.google.com

23 pointsabrax31417 comments

My conclusion is that LETTER is a categorization subroutine that categorizes characters into one of 14 types. Type 2 is minus sign, 4 is alphabetic character, 5 is period, 6 is right paren, 9 and 13 are blanks, 10 is left paren. Types 1, 3, 7, 8, and 11 are single characters (presumably different special characters). Type 12 is a digit. Type 14 gets handled as a single character or alphabetic character depending on circumstances.

The LETTER routine operates on a word of 6 characters at a time, producing 6 categorizations. The results of LETTER are stored in the variable KNOW, which is then used for a switch statement Z(IDENT), which transfers to W4, W5, W6, etc, which perform the appropriate action for the character type: creating a number, creating a sublist, creating a word token, or so forth.

Some other random things I determined on the way to this: IS is the parenthesization level, IC counts the character within a card (1 to 6), and IW counts selects the card (1-14). KGETBL and KGETIN extract one character from the specified word. I think KGETBL extracts it as a character and KGETIN extracts it as an index. MADIN converts its argument from a MAD language variable to an assembly variable, while MADOUT converts an assembly variable to a MAD variable.

Team ELIZA (and friends) are trying to make the original ~1965 MAD-SLIP ELIZA (discovered a few years ago in Jospeh Weizenbaum's MIT archives) run. A number of semi-overlapping groups are involved in this. Some have a 7090 emulator, some have a CTSS emulator on that, and some have various versions of MAD, SLIP, and the underlying FAP (IBM's Fortran Assembler) code that runs SLIP. (Yeah, I know. Go ahead and get the laughter out of your system. I did't name it!)

We (they) have this mostly under control, but for one single function, called "LETTER." that we cannot find the code for, and are having trouble divining the function of.

The code of concern is here:

  https://drive.google.com/file/d/1zAJ2zX9WaeR7Ui8F88ZNFZtI5Q-Ow5sb

If you search for "LETTER." there is a single call to it on card 00386. (MAD functions all end with "."; There are several occurrences of LETTER as labels, but only one function call.) This is in the function(entry) LISTRD. (000096) [This was in the days when functions could have multiple entry points in order to conserve memory.] and is used to load an array called KNOW (indexed by I). LISTRD is an s-expression reader (but into SLIP not LISP -- see below for LISTRD documentation).

Some potentially important factoids: The 7090 had 36 bit words and packed 6, 6-bit BCD characters into each. (You can see this in line 000356 where it appears to be packing 6 close parens (BCD 34k) into a word: CARD(I)=343434343434K (K for octal). Notice cards are (were) 84 characters in width and 84/6 is 14 -- the number 14 is used in multiple places as a loop limiter, so it's apparently scanning across cards (and the minimal comments and some variable names suggest this as well).

[Unfortunately, comments were used quite sparingly in those days because you had to punch them into cards!]

Again, the only function for which we don't have code is LETTER. So, okay, Sherlock Hackers...What exactly does LETTER. do and what exactly is it doing here?

Here's a SLIP manual:

   https://drive.google.com/file/d/1XtF7EM1KhwMPKsp5t6F0gwN-8LsNDPOl

LISTRD is documented on pg. 24 of the above manual.

(Possibly important is that lists had to start in column 1 with an open paren.)

ChatGPT seems to know the answer. Is it not correct, or would you prefer verification by a human?

> Notice cards are (were) 84 characters in width

Maybe I'm misunderstanding what you mean by a card, but the 7090 used 80-column punch cards of which 72 columns could be read into the computer. (Which is why Fortran used 72-character lines.) The 7090 had a plugboard so you could select which 72 columns you wanted, but normally it would be the first 72. Why 72? Because cards were read "sideways" and 72 columns fit into two 36-bit words.

> Because cards were read "sideways"

That is, cards were read row by row, not column-(character)-by-column — one ‘bit’ from every character at once. And this is the case for practically all card equipment. That surprised me a bit when I first learned it, as someone used to sequential character streams, but it makes sense in the context of pre-computer card operations, where cards and holes started and stopped counting wheels for each digit (column) at once to calculate totals.

The IBM System/360 moved to card readers that operated column-by-column, e.g. the 2501 card reader or the 2560 Multi-Function Card Machine. As you said, reading row by row makes a whole lot of sense when you have electromechanical equipment. It's amazing that they could build things like card sorters without any electronics, just a brush and solenoids.

You might already know this but here’s my guess:

OK, so this looks like it’s reading one card’s worth of code from either an actual card or tape. Based on how KNOW is used, the mystery LETTER looks like it’s classifying each word based on what type of token it is… then it goes into an interpreter loop with what’s basically a switch statement on the IDENT of each word (derived from its entry in KNOW). So I think each card could have 14 tokens of up to 6 chars each, some only one character (like a parenthesis) or some an entire literal?

A108 is the per-word outer loop and A105 is the per-char inner loop. A102 and A104 are the labels where the loop indices are updated and it jumps back to the beginning of the loop. As far as I can tell, MADIN and MADOUT are no-ops. I’m not sure what KGETIN is doing.

I believe the 343434343434k is meant to simulate some extra cells with a bunch of right parens so you could just end your program without wasting another card on closing everything?

Edit: I just read page 24 of the linked SLIP manual and what I’m calling tokens they’re calling SLIP cells.

Reply on news.ycombinator.com