Here's a slightly more involved version - this reads two values, so we can see how 'varargs' style lists work:

VECTOR VALUES FMT = $F9.4,F9.4*$
READ FORMAT FMT,N,M

The machine code output (as loaded by the program loader) is attached - the 'READ' call is indicated in red. This is linked to the OS routine '.READ', which the documentation (also attached) lists as a compatibility routine for MAD.

1/n

#CTSS #retrocomputing #IBM7094

Location 21 is a TSX (transfer and set index) to the entry for .READ in the transfer vector. This is the standard way of entering subroutines - TSX jumps but stores the current location in an index register, which is then used as an offset for arguments and the return location. The transfer vector is at the start of the section, where the loader puts the locations of symbols imported from other modules.

2/n

Location 22 is the first STR entry from the documentation. This looks like it's using the 'STR SYMTB,DIR,FMT' variant. I have no idea how it knows which version you're using. Reading from right to left (as is the convention for FAP), we have:

address = 05407 (symbol table)
flag = 1 (direction)
decrement = 05366 (format)

Note that the direction value means that the format string is read backwards from 05366 (i.e. '(MAIN)+6'), and is two words plus what I assume is a null terminator (although the string is also separately internally terminated with a '*'). The machine uses a 6 bit BCD character set, so each 36 bit word is 6 characters.

3/n

I don't know anything about the symbol table. The address corresponds to (MAIN)+27, which is the two words of zeros at the end of the code. I guess it makes sense that the the test program doesn't export any symbols, so the list would be empty, but why does .READ need to know about that? At some point I'll update the test program to export something and see what that looks like. I should also compare the binary file on disk with the memory image - I don't yet know how it knows where the symbol table is (or where the program entry point is for that matter).

4/n

Note that the backwards direction for the format string makes sense, as the index registers on the #IBM7094 work that way - in indexed addressing mode the index register is subtracted from the base address.

5/n

Locations 23 and 24 are references to the N and M variables, so it looks like the list of locations to receive the input might be a null terminated list. This is not at all what the documentation says. I can only guess that there's a version difference between the 1965 version I have the documentation for and the early 1970s version of the code I have. Null termination feels more modern, and is more flexible as it would let you read data into non-contiguous memory. I'll add to the to-do list writing a test program to see if the calling convention as documented also works.

6/n

Finally, it looks like .TAPRD, which reads from tape (or in practice a file on disk emulating a tape) is pretty much a drop-in replacement for .READ, so it should be pretty easy to try that one out. In the past I've had problems with it ignoring the file number argument though, and I do need to have multiple tapes if I'm going to use them for both input and output in #musicn

7/7

#retrocomputing #IBM7094 #CTSS