Auto-Loder

return to main 1401 Restoration Page

from Keith Falkner < keithfalkner@gmail.com > Jan 25, 2011
Dear Ed et al,

I wrote code in an environment where programmers sat and operators operated, so the turnaround time for an assembly was half a day, and the turnaround time for a test was about the same. Any measure that would provide an extra test per day was a helpful boost to our productivity.

Understand that when Auto-Loder processed a source deck, it produced executable code only, no listing or documentation of any kind. There were limitations:

  • a label is 2 or 3 characters, and must be unique
  • an actual address must be 2 or 3 digits
  • put your constants and workareas before your executable code, never amid or after it.
  • DA must be 1Xlength, never 2X or moreX.
  • if col 36 of an executable line is not blank, then it is treated as another opcode, with operand starting in col 41; ditto col 56 if col 36 is used thus
  • I do not think literals were allowed, but perhaps short ones were OK.
  • no address adjustment, except in EQU commands.
And there were no diagnostics of any kind, just a crash and, if the operator obliged, a scribbled indication of the I-, A-, and B-Registers, and a core dump. So if you used a 4-byte label or a one-digit operand, as in MCW 8,SEQ, then Auto-Loder would provide a gibberish instruction and there is your Process Check.

Here is what would happen to this line of a program:

JOE BCE UPD,75,K

  • Lookup BCE and find it means opcode B. If this is the first opcode (as opposed to DCW, DA, EQU, ORG ...) then remember where it lands, to stop a later translation scan
  • Increment location counter.
  • Add JOE to symbol table with current location counter as address.
  • put B with word mark into core (it feels odd to refer to memory thus!). col 22 is not blank, so an A-operand is coming. (If col 22 is blank, and 21 is not, then 21 is a D-modifier, as in SS 2). col 23 is not comma, plus, or -, so the operand is in col 21-23.
  • Add 3 to location counter and put UPD into memory, just as it stands.
  • Similarly find B-operand 75 and put 075 after UPD
  • Find D-modifier K and put it after 075, leaving the location counter at K.
When END is reached, *1 Scan backward from the current location counter to the location of the first executable instruction, referring to the symbol table to change BUPD075K into BY74075K because UPD is in the symbol table as location 1874 (Y74). *2 Then jump to the value of the label in the END card.
- - - - - - - - -
*1 - If the source program used the opcode CALL, then CS 80, SW 1, Read-and-branch to 1, because the programmer sez that a Library program is participating with Auto-Loder to expand Auto-Loder's power. That program must interact intimately with Auto-Loder, and I wrote a few that did that very well. For example, one added reliable tape-I/O code and a few of the more useful routines that were part of the Toronto jargon at the time. This program then branches back to the location in Auto-Loder that initiates the backward scan.
- - - - - - - - -
*2 - Again, if the source program used CALL, another visit is made to the Library program just before the loaded program is initiated.

Eventually, Auto-Loder, modified by me, produced a fair mockery of an Autocoder listing, plus a couple of pages of program documentation, and then you got your choice of immediate execution, or a punched-out object deck. At your peril, you could ask for a deck and then include instructions for the operator to load it in and test your program, but not every operator was adept at following complex instructions like those!

I do not think there is any point in trying to bring Auto-Loder back from the dead, because ROPE provides so much more, putting the whole machine at your fingertips, as it were.

Why can't I ever write anything brief?
Ed says: 'cause some things ain't simple, like me

Keith

and a few minutes later ;-)) 

Hi, Van.

Auto-Loder was smarter than you have written it. It looked at the length of the
instruction it was compiling, and translated symbols to addresses in positions:

    (none) of a 1- or 2-byte instruction,
    123 of a 3-character adcon,
    234 of a 4- or 5-byte instruction.
    (I think it left six-byte words alone, as they could not be instructions.)
    234 and 567 of 7- or 8-byte instructions.


If it found B333J29R, it would know J29 is a label, not location 2129, 
because the programmer had no way to tell Auto-Loder the B-field was to be location 2129.
 It would know 333 wasn't a label, and it would not treat B33 as a label.

So yes, DSA would work, but only if placed higher in memory than the first executable 
instruction. That "first executable instruction" was mighty important. 
I think only four of a dozen programmers became adept in using Auto-Loder, 
but it was very helpful for simplifying the running of a test. If I want to test a 
program that reads 70-character records from tape, and the standard test setup 
includes a scratch tape on unit 2, then I can either send an input tape with my test
 deck, or include an Auto-Loder program to read cards and make the tape:
GMW     DA   1X00,G
MAS     EQU  %U2
BEG     RWD  MAS
RED     R
        BCE  QUT,01,,      FC of program?
        LCA  GMW,71        GMWM to make 70-char rec
        CALL WRT           Write test data.
        DCW  WM
        B    RED
QUT     WTM  MAS
        RWD  MAS
        CW   71
        SW   01
        B    01
WM      DCW  29
        DCW  000
        WT   MAS,01
        END  BEG

That was pretty easy, and it uses a canned routine WRT to handle tape errors 
in a reasonable fashion. I would put the Auto-Loder program (76 cards) in my tray,
 then the above program, then the CALL deck (95 cards, I think), 
then the data to be my input tape records, then the program I wanted to test.

There were many drawbacks to supplying a tape of test data: the operator would 
take a couple of minutes to mount it, and another to remove it, the tape might 
suffer a fall, the operator might lose it, etc. 
A 1402 can read a lot of cards in the time it takes an operator to mount a tape!

I found that Auto-Loder freed me from complexities such as Auto-Test 
(truly a wonderful program) and FAST (Fourteen-oh-one Automated System of Testing). 
Operators came to recognize my tray with at least one Auto-Loder deck in it, 
as a test that pretty much ran itself without any messes. 
Sometimes I included a core-dump, and patched the program under test to BLC to a halt,
 else read a card and branch to 1 if it was a comma.

And of course the core dump was patched to load the following Auto-Loder program
 to print out my output tapes.

Next chapter: Patching with TIPSY

Keith

OH MY - I'm falling behind :-(( 


Dear All,

I described an environment where turnaround was about half a day, for either 
an assembly or a test. So we tried to patch our programs, and someone found 
a patching program, about 22 cards, that simplified the process of correcting 
small parts of a program.

For example, I have a symbol error at 4178

04178 L ### E98

I misspelled an operand, and the data I want to load is at 9430. Of course I 
could paw through the object deck and find card 0238 (say) and find ### in 
columns 21-23, and duplicate the card except key U3? instead, multi-punching 
hyphen and zero where the question mark is shown, but that is tedious and 
error-prone. And I am not sure that is the correct multi-punch pattern for 
address 09430. Are YOU???

Instead I punch these two cards:
?04178      Record mark in col 1 means ORG
L#09430E98?     #-sign means convert 5-digit address
                       and the record mark means the end of the instruction.

Here's another error.

06166 E F56 289

I forgot to load my Edit Mask to 289 so the MCE command crashed.
Here's what I do:
?06166     ORG to the MCE instruction
B#15101?    overwrite it with branch
N?                 and a NOP to get a WM
?15101      ORG to a void area above my program
LF42289?     Load my edit mask
EF56289?     Recode the clobbered MCE
B#06173?     Go back to NSI

To make this all work, I stick my TIPSY (The Invisible Patching SYstem)
deck in front of the SECOND-LAST card of my object program, and my patches 
between the second-last card and the last card of the object program. TIPSY 
loads into 100-332 and 15900-15999, reads the second last card and learns the 
highest address my program uses (col 44-46), modifies col 68-71 of that card, 
goes to col 40, reads and loads my patches, then clears itself from memory 
and jumps to the CS instruction in column 40 when it finds a blank in column 1 
(or maybe I mean all blank in 01-39).

I admit I have forgotten something. I really didn't need to find that 
void area at 15101, because TIPSY did that for me. I just do not recall 
the lingo for "Branch to the void area where you are going to assemble 
my patches". It may have been B*000; I know that the asterisk was very 
useful for referring to stuff in that area.

I have no idea what the record number of TIPSY patch cards was, but I 
recall finding TIPSY decks in production programs and thinking that was 
a truly wretched level of sloppiness.

Keith