IBM 1130

IBM implemented five models of the 1131 Central Processing Unit, the primary processing component of the IBM 1130. The Model 1 through Model 5 describe the core memory cycle time, as well as the model's ability to have disk storage. A letter A through D appended to the model number indicates the amount of core memory installed.

IBM 1131 Central Processing Unit weighs about 760/1050 lb (345/477 kg).[5]

The Model 4 was a lower-priced product with a 5.6 μs cycle time. Some purchasers of performance upgrades observed that the field adjustment to achieve the improvement was surprisingly trivial.

The IBM 1132 printer relies on the 1130 processor rather than internal logic to determine when to fire the print wheels as they rotated. Printers for the Model 4 run more slowly, but the slower processor still can not keep up with it. The hardware manual discloses that when the Model 4 was servicing the two highest-level interrupts (the level 0 card-reader column interrupt or the level 1 printer interrupt), it ran at the faster 3.6 μs cycle time. Some users of the Model 4 would write a phony printer driver that did not dismiss the printer interrupt, in order to benefit from the higher processor speed. However, lower-level interrupts are disabled during this interval, even the end-of-card interrupt (level 4) from the 1442 card reader.

The IBM 1800, announced November, 1964,[6] is a predecessor of the IBM 1130 for process control applications. It uses hardware rather than core memory for the three index registers and features two extra instructions (CMP and DCM) plus extra interrupt and I/O capabilities. It is a successor to the IBM 1710, as the IBM 1130 is a successor to the IBM 1620.

The IBM 1500 is a multi-user educational system based around either an IBM 1130 or an IBM 1800. It can connect to up to 32 student work stations, each with a variety of audio-visual capabilities.

Other than these, IBM produced no compatible successor systems to the 1130. The IBM System/7 is a process control and real-time system, and the IBM Series/1 is a general-purpose 16-bit minicomputer, both having different architectures from the 1130, and from each other.

• February 11, 1965 – IBM introduces the 1130 (Models 1A, 1B, 2A, and 2B). Also announced is the IBM 1132 printer, the lowest cost online computer printer ever announced by IBM at that time.
• Fourth quarter 1965 – First customer shipments begin from the San Jose plant.
• March 31, 1966 – IBM introduces the IBM 1500 educational system.
• April 1966 – IBM 1800 ships.[7]^: 497
• August 9, 1966 – IBM rolls out the 1130 synchronous communications adapter, which permits the small 1130 system to be connected by regular leased telephone lines to, and function as a communications terminal for, any model of the IBM System/360.
• April 17, 1967 – A four-way expansion of the 1130 is announced (Models 2C, 2D, 3B, 3C, and 3D), involving:
  • Five times the disk storage and four times the core memory;
  • An additional processing speed almost 40 percent faster than previously available;
  • More and faster peripheral equipment, including an optical mark reader;
  • An improved commercial programming package.
• January 1968 – First shipments begin of the 1130 Models 2C, 2D, 3B, 3C, and 3D.
• July 1968 – The Boca Raton plant begins shipping the 1130.
• July 22, 1971 – 1130 Models 4A and 4B are introduced at new levels of economy.
• September 1971 – First customer shipments begin of the 1130 Model 4.
• May 31, 1972 – Models 1C, 1D, 5B, 5C and 5D are announced.
• 1973 - The Xerox 530 was marketed as a possible successor to IBM 1130 customers.[8][9][10] Orders for the Xerox 530 were deemed "encouraging" as of January 1974.[11]

Monitor control records are identified by //␢ followed by a "pseudo-operation code" in columns 4–7. "␢" represents a single blank.

The JOB record can have a "T" in column 8 to indicate that any files added to the User Area by this job should be deleted at the end. Columns 11 thru 15 can contain a cartridge label; the system verifies that the specified cartridge is mounted before proceeding.

The XEQ record may contain the name of the program to be run in columns 8 thru 12. If this is omitted, the program currently in Working Storage will be executed. If column 14 contains "L", and the program is in Disk System Format (not core-image) a core map will be printed by the Core Load Builder. If this statement is followed by LOCAL NOCAL, or FILES Supervisor Control Records, columns 16 and 17 contain the count of these records. Column 19 optionally indicated which disk driver routine is to be linked. "0", "1", or "N", request DISK1, DISK2, or DISKN, any other character, including blank, requests DISKZ, the FORTRAN disk routine.

Supervisor Control records begin with an "*" in column 1, immediately followed by the command pseudo-operation in column 2. They are LOCAL, NOCAL, and FILES for the Core Load Builder. DUP control records have a similar format. These records control program linking, either for the // XEQ statement or the DUP *STORECI command.

The 1130 has no hardware support for a stack. Most subprograms are called with the instruction BSI (Branch and Store IAR). This deposits the value of IAR (the return address) at the destination address and transfers control to destination+1. Subprograms return to wherever they were called on that occasion using an indirect branch through that first word of the subprogram. Placing the return address in-line was a common technique of computers at that time, such as the Hewlett-Packard HP 2100,[30] the DEC PDP-8,[31] and the Scientific Data Systems SDS 920.[32]

So a subprogram named SIMPL might be organized as follows (comments follow the instruction operand):

SIMPL: DC     *-*    This is the entry point, filled with a zero initially.
       (whatever the routine does)
       B    I SIMPL  Return by an Indirect branch, to the address found in location SIMPL.
       END    SIMPL  Instructs the assembler that the source for routine SIMPLE is complete.

The subprogram would be called as follows:

       BSI  L SIMPL  Call SIMPL. L (Long) is needed if SIMPL is more than -128 or +127 words away.

The pseudo-opcode CALL would typically be used.

As shown, a subprogram's entry point is DC *-*, an assembler pseudo operation that is used to Define a Constant (occupying one word of storage) with the value specified by the expression. The * stands for the current address of the assembly and so *-* results in zero. Writing this rather than 0 provides a visually distinctive note that a meaningful value (the return address) will be placed there at run time. The entry point need not be the first word of the subprogram. Indeed, the preceding word can be the start of a two-word direct branch instruction whose address field is at SIMPL. Then, returns can be effected by one-word branches there: B SIMPL-1

When SIMPL is called, the BSI instruction replaces *-* with the current value of IAR, which is the address just past the BSI instruction. After SIMPL does whatever it is written to do, B I SIMPL branches not to SIMPL, but indirect through it, thus continuing execution with the instruction following the BSI instruction that called SIMPL.

Without extra arrangements to protect the return address, recursion is impossible: If SIMPL calls itself, or called a subprogram that called it, its original return address is overwritten. Re-entrancy is problematic for the same reason: An interrupt service routine must refrain from calling any subprogram that might have been the code that was interrupted.

The caller of SIMPL might pass it parameters, which might be values or addresses of values. Parameters might be coded in-line (immediately following the BSI instruction) or might be placed in index registers XR1 and XR2. If parameters are placed in-line, SIMPL modifies its own return address so its final indirect branch returns beyond the parameters.

Integer functions of a single integer expect the parameter in the accumulator and return their result there. Floating-point functions employ the floating-point accumulator (a two word area set aside by the floating-point library, three words for extended precision), and so on.

The convention of coding 0 as the initial value at the entry point means that if a programming error leads to SIMPL returning before the first time it was ever called, execution would jump to memory location 0. As mentioned above, it is customary to have location 0 contain a branch to location 0. The 1130 would be stuck at location 0, and the IAR lights on the console would be entirely dark, making it clear the program had failed.

For subprograms that would be called many times (for example, subprograms for floating-point arithmetic), it is important to reduce the size of each call to one word. Such "library routines" use the LIBF protocol. It is more complex than the CALL protocol described in the previous section, but LIBF hides the complexity from the writer of the assembly-language program.

Library routines are addressed through index register XR3. (Fortran subprograms use index register XR1 for the addresses of parameters and the return address, but register XR2 is unused.) XR3 points to a sequence of three-word transfer vectors such that the first entry is -128 words from XR3's value. The programmer calls the library routine using the LIBF pseudo-operation, which assembles not a direct BSI to the routine but a one-word indexed branch instruction (BSI 3 disp) whose displacement (-128, -125, and so on) identifies the start of the routine's transfer vector.

The transfer vector is prepared by the linkage loader when it puts together the program. A transfer vector entry to a library function named SIMPL takes this form:

      DC       *-*            A word into which BSI stores the return address.
      B    L   SIMPL          Branch to the start of the library function.

The way SIMPL knew where its return address was is that, if SIMPL were declared a LIBF routine, the linkage loader would modify the code of SIMPL, placing the address of SIMPL's transfer vector entry at SIMPL+2. LIBF routines, unlike CALL subprograms, do not start with a DC directive to hold the return address (it is in the transfer vector) but with actual code, as follows:

SIMPL STX   1  RCVR1+1        Save the caller's value of XR1 at a nearby location.
      LDX  I1  *-*            The linkage loader changes the address word to point to the transfer vector.

Placing the address of SIMPL's transfer vector at SIMPL+2 leaves room for a one-word instruction to save the chosen index register, here XR1. Then the indirect LDX instruction points XR1 not at the transfer vector, but through it to the return address, or to any parameters stored in-line after the BSI. SIMPL then does whatever it was written to do, gaining access to any in-line parameters through XR1 (in which case it must increment XR1 for the return address), and returns as follows:

      STX   1  RETN+1         Store XR1 to prepare to use it as a return address.
RCVR1 LDX  L1  *-*            SIMPL's first instruction modified this address.  Now,
*                              restore the original value of XR1.
RETN  B    L   *-*            This instruction was modified two instructions ago; return.

Example

Suppose a LIBF-style call to SIMPL were at address 100. Then the return address would be 101, because BSI 3 disp is a one-word instruction. XR3 points into the group of transfer vectors. If the transfer vector for SIMPL started at address 2000, then the BSI would be assembled with a disp so that XR3+disp = 2000. Executing the BSI stores 101 at location 2000 and jumps to location 2001. At 2001 is a two-word long jump to the entry point of SIMPL, which the linkage loader might have placed at address 300.

The long jump transfers control to SIMPL. After the instruction at 300 stores XR1, the instruction at 301 is LDX I1 2000, the linkage loader having placed 2000 at location 302. This does not load 2000 into XR1; it is an indirect instruction, and loads the contents of 2000, which is 101, the return address for that call to SIMPL.

In the return sequence shown above, by the time control reaches RETN, the instruction there is B L 101, which returns to the caller. (If there is one or more in-line parameters at 101, SIMPL would increment XR1 to point to 102 or beyond, and this would be the destination of the B instruction.)

Variations

If SIMPL took parameters coded in-line following the BSI instruction, SIMPL gains access to them with indexed addressing off XR1. The first could be obtained by LD 1 0, the second by LD 1 1, and so on. If the second parameter is the address of the actual parameter, then LD I1 1 obtains its value. Before returning, SIMPL increments XR1 past the n parameters with an instruction such as MDX 1 n so as to place the right value at RETN+1.

A LIBF routine that declined to restore the original value of XR1 could omit the above steps and return with a simple B 1 n to skip n in-line parameters. However, such a routine can not be called by other LIBF routines because it disrupts the caller's use of XR1 for access to its own parameters and return address.

The complexity of LIBF saves memory for subprograms that are frequently called.:[33]^: p.24 The LIBF linkage requires one word per invocation, plus three words for the transfer vector entry and extra code in the routine itself, whereas the CALL linkage requires two words per invocation because most CALLs will be to an address beyond the -128 to +127 word reach of the one-word opcode.

The register XR3 must point to the transfer vector entries for the library routines rather than a dispatch table of only their addresses, because this latter would require that LIBF routines be called with an indirect BSI instruction. These instructions are two words long, so such a design would negate the code size savings of LIBF. The eight-bit limit for the disp field of the one-word instruction code limits usage of LIBF routines to no more than 85 distinct entries.

The previous sections show that code and data are intermingled. It is common in 1130 programming to modify the address fields of instructions and, in fact, to modify entire instructions.

The Fortran compiler produces self-modifying code when generating code for any subprograms (subroutines or functions) that have parameters. The compiler builds a table of every location where the subprogram references one of its parameters, and compiles as the first instruction in the body of the subprogram a call to a subprogram called SUBIN that uses the table to modify the address field of every reference to a parameter to be the actual address of the parameter during the current invocation. SUBIN makes these patches every time the subprogram is called.

When a Fortran program calls a subprogram, the addresses of any parameters appear in-line following the call. For example, the Fortran statement CALL SIMPL(X) might compile into:

  BSI L  SIMPL
  DC     X      The address of X, on which SIMPL is to operate

Within the subprogram, parameters could be accessed by indirect indexed addressing as shown above in Variations, so, given that XR1 has been suitably prepared, an integer parameter could be loaded into the accumulator with an instruction like this:

  LD  I1 0      Load the value of the first parameter (offset 0) into the accumulator

The compiler instead used direct addressing. When SUBIN runs, it obtains the address of X and patches the instruction's address field to become:

  LD  L  X      Load the value of X into the accumulator

The advantages of SUBIN are as follows:

• To obtain the operand's address an indirect indexed instruction requires three memory cycles (the index register being in memory) while the direct access instruction require only one.
• If SIMPL were to pass one of its parameters to any subprogram that expected to receive the address of its parameter (including all the LIBF routines for floating-point arithmetic), SUBIN is needed to supply the actual address of the original parameter.

The disadvantages of SUBIN are the time it requires to run and the memory required for the table of references. The size of this table is the sum of 5, the number of parameters, and the number of references; if this sum exceeds 511, compilation will fail. For subprograms with many references to a parameter, the author of the subprogram might copy the parameter into a local variable.

Modifying entire instructions was a common technique at the time. For example, although the 1130 has an OR instruction, the syntax of Fortran provides no way to write it. An integer function IOR can be defined, enabling logical OR to be part of a Fortran expression such as:

   M = 3*IOR(I,J) + 5

The Fortran compiler places the addresses of I and J in-line and expects the result in the accumulator. Using IOR(I,J) in a Fortran expression compiles the following four words:

  BSI  L IOR    Two-word jump to the start of the IOR function.
  DC     I      A one-word in-line parameter: The address of I.
  DC     J      A one-word in-line parameter: The address of J.

In fact, the assembler IOR function does not compute I or J at all. Instead, it replaces the above four words with the following:

  LD   L I      Load accumulator with I (two-word instruction)
  OR   L J      OR accumulator with J   (two-word instruction)

After performing that transformation, it does not return past the end of the four-word block (which it had just modified). Instead, it branches to the exact address from which it had been called originally. The BSI instruction is no longer there; what is now there is the two instructions it has just written. They combine the two integers with the machine-language OR instruction and leave the result in the accumulator, as required.

The call to IOR and the transformation of the four-word block happens at most once per program run. If the Fortran line illustrated above is executed again, it runs faster than it did the first time. Similar functions could be devised for other useful operations.

A function that self-modifies, as IOR does, can not be used in a Fortran subprogram on any of the parameters to that subprogram (though it could be used to combine local variables) because it is incompatible with the SUBIN subprogram discussed above. IOR's transformation of its four-word calling sequence, shown above, moves the location of the address of variable I. On subsequent calls to the Fortran subprogram, the table of references to parameters would be in error and SUBIN would patch the wrong word, in this case placing the new address of I over the OR operation code.

1130 FORTRAN offers two floating point formats: a 32-bit "standard precision" format and a 40-bit "extended precision" format.

Standard precision format contains a 24-bit two's complement significand while extended precision utilizes a 32-bit two's complement significand. This format makes full use of the CPU's 32-bit integer operations. The extended format occupies three 16-bit words, with the high-order eight bits of the first word unused. The characteristic in both formats is an 8-bit field containing the power of two biased by 128. Floating-point arithmetic operations are performed by software.[34]

The *EXTENDED PRECISION compiler option card tells the FORTRAN compiler to use 40 bits instead of 32 bits for all floating point data, there is no provision for mixing formats.

Data to be manipulated and the instructions that manipulate them have to reside together in core memory. The amount of installed memory (from 4,096 to 32,768 words) is a key limitation. Fortran provides several techniques to write large programs despite this limitation.

LOCAL subprograms

Fortran let any subprogram be designated as "LOCAL" (Load-on-Call). Each LOCAL subprogram is an overlay; it is part of the disk-resident executable program but is only loaded into core memory (if not already there) during the time it is called. So, for example, six LOCAL subprograms would require only as much core memory as the largest, rather than the total amount for all six. However, none of the six can invoke another, either directly or through intermediary subprograms.

Programs in phases

An entire Fortran program can pass control to a subsequent phase, exiting to the Supervisor with an instruction to load the follow-on phase into core memory. A large program might be split into three parts, separately compiled, called PART1, PART2, and PART3. Execution is started by // XEQ PART1 and at a suitable point, PART1 would execute the Fortran statement CALL LINK(PART2) and so forth. The name of the successor program in the CALL can not be variable, but program logic can govern whether control is transferred to another phase, and which CALL LINK statement is executed. As mentioned above, the Fortran compiler itself was written this way, with each phase of compilation achieved by a separate program.

COMMON data storage

Programs, such as Fortran programs, reside at low core memory addresses (just above the Supervisor). Fortran allocates space at the highest addresses for any variables and arrays declared COMMON. If a follow-on phase of the program contains a corresponding COMMON declaration, then information in this common area can be shared among phases. Phases could omit the COMMON declaration without problem, provided those phases were not so large as to have their program code invade the common area. COMMON storage not only shares data between phases; lower-memory COMMON variables can be used to pass data among a main program and subprograms within a single phase, though the data could be lost on moving to the next phase.

The following listing shows a card deck that compiles and runs an assembler program that lists a deck of cards to the line printer.

 // JOB
 // ASM
 *LIST
                     * LCARD.ASM - LIST A DECK OF CARDS TO LINE PRINTER
                     *
                     * 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. If source changes were needed the programmer would duplicate the cards to obtain a deck with columns 1-20 blank ready for the next run through the assembler.

By convention, buffers are preceded by a word count. The DC (Define Constant) assembles a count word and the following BSS (Block Started by Symbol) 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, with a bit set to on for each hole punched 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 only case of two devices using the same character encoding.

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. Despite appearances, the statement 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, though one occupying two words of storage: the BSI operation code word for the CALL is unused and thus usually wasted, but the second word of the expansion of CALL HLEBC is the address of the HLEBC table needed by 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.

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 even though it has two separate work areas; 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 1442 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.

The following image shows a simple APL \ 1130 session. This session was performed via the 1130 simulator available from IBM 1130.org

The above session shows a signon, addition of the integers 1 to 100, generation of an addition table for the integers 1..5 and a sign off.