IBM 1130 - Programming Examples - Sample Assembler Program Deck

Sample Assembler Program Deck

The following listing shows a card deck that compiles and runs an Assembler program that lists a deck of cards to the line printer.
The following code Copyright (c) 2006 Kym Farnik. Code published under MIT license. See: http://www.opensource.org/licenses/mit-license.php

// JOB // ASM *LIST * LCARD.ASM - LIST A DECK OF CARDS TO LINE PRINTER * * COPYRIGHT (C) 2006 KYM FARNIK. * CODE PUBLISHED UNDER MIT LICENSE. * * PROGRAM * NEW PAGE ON PRINTER * A READ A CARD * CONVERT FORMAT * PRINT A LINE ON PRINTER * GOTO A * START LIBF PRNT1 GOTO NEW PAGE ON 1132 DC /3100 PRINTER CHANNEL 1-NEW PAGE * NEXTC LIBF CARD0 READ FROM 1442 CARD READER DC /1000 CONTROL TO READ DC CBUFF STORE 80 COLUMNS CINP LIBF CARD0 DC 0 B CINP LOOP UNTIL CARD IS READ * LIBF ZIPCO CONVERT CARD TO PRINTER DC /1100 UNPACKED IN, PACKED OUT DC CBUFF+1 INPUT BUFFER DC PBUFF+1 OUTPUT BUFFER DC 80 CHARACTER COUNT CALL HLEBC HOLLERITH TO EBCDIC * LIBF PRNT1 PRINT 80 CHARACTERS DC /2000 CONTROL CODE TO PRINT DC PBUFF PRINT BUFFER DC PERR PRINT ERROR POUT LIBF PRNT1 CHECK FOR PRINT COMPLETE DC 0 B POUT LOOP UNTIL COMPLETE * B NEXTC READ NEXT CARD * * DATA * CBUFF DC 80 80 COLUMNS PER CARD BSS 80 * PBUFF DC 40 40 WORDS 80 CHARACTERS BSS 40 * PERR DC 0 B I PERR THIS RETURNS TO THE * PRINTER ERROR HANDLER * WHICH WILL TERMINATE THE PROGRAM * END START PROGRAM ENTRY POINT // XEQ TEST DATA 1 HELLO WORLD TEST DATA 2

In this job, the assembler leaves the result of its assembly in the temporary area of the system disk, and the XEQ command executes the content of the temporary area. The odd-looking END START has two meanings: end of assembler source, and the name of the entry point of the routine, which has the label START.

Assembler source starts with column 21 of the card, not column one. In systems without a disk drive, the assembler would punch code into the start of the card just read (the card reader was actually a reader-punch, with the punch station after the read station) and then read the next card. To handle forward branches and the like, the assembler's second pass literally involved a second pass of the cards through the reader/punch. And should you need to change the source deck, you would have to duplicate the cards to obtain a deck with blanks at the start ready for the next try through the assembler.

By convention, buffers are preceded by a word count. The DC assembles a count word and the following BSS reserves the required number of words for the buffer. The card buffer requires 80 words, one for each card column. Driver CARD0 reads each card column literally, using 12 of the 16 bits in the buffer word to describe whether there is a punch in the corresponding row for that column. The pattern of punches typically describes a text character using the Hollerith code. The console keyboard also gives input to the program in the Hollerith code.

The printer routine, however, works with text in 8-bit EBCDIC with two characters per word, requiring a 40-word buffer. The program uses library routine ZIPCO to perform the conversion. The CALL HLEBC is not executed because HLEBC is not a subroutine but an IBM-supplied Hollerith-to-EBCDIC conversion table. The CALL statement provides the address of the table to ZIPCO and ensures that the linking loader includes the table in the program, thus it is the fifth parameter to ZIPCO. After the conversion, the program sends the converted output, now in buffer PBUFF, to the printer through driver PRNT1. Again, the program loops until the printer driver reports completion, then the program reads the next card.

This example contains no code to decide when to stop. A more complete program would check for cards that begin with //, which denotes the start of the next job. To stop the card reader as soon as possible, a program could check for the Hollerith code of / before even converting the card to EBCDIC.

Asynchronous I/O and performance

The call to CARD0 to read a card initiates that operation and immediately returns to the caller, which could proceed with other activity. However, the example program makes no attempt to overlap input and output using buffers; it simply loops back to CIMP to test afresh. After CARD0 has sensed the card reader's operation-complete interrupt, it returns one word further on, thus skipping the jump back to CIMP and leaving the loop.

The example routines do not run the I/O devices at top speed. Notably, the card reader, only a few milliseconds after reporting completion on reading a card, will commence its stop sequence, after which a new read command will have to wait to initiate another read cycle. The IBM 1402 reader could read 400 cards/minute at full speed, but just a little hesitancy in the read commands would halve its throughput or worse. A Fortran program could not complete even the simplest input processing in time, and so could not read cards at full speed. One common Fortran DO loop to read cards made the motor stop and start so frequently as to accelerate wear. With buffering, the card reader control could be overlapped with processing, and the reader could be run at full speed through large data decks, but memory for the more complex program and for buffers was often at a premium.

Even with assembler and double buffering, a program to list a deck of cards from the IBM 2501 reader (1,000 cards/minute) on the line printer could not keep up, as the translation from card hole patterns to EBCDIC for the printer as done by EBPRT was too slow; the more complex ZIPCO and HLEBC were needed instead, as in the example.