| 词条 | IBM 1130 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 释义 |
The IBM 1130 Computing System, introduced in 1965,[1] was IBM's least expensive computer at that time. It was aimed at price-sensitive, computing-intensive technical markets like education and engineering, succeeding the IBM 1620 in that market segment. The 1130 was also used as an intelligent front-end for attaching an IBM 2250 Graphics Display Unit, or as remote job entry (RJE) workstation, connected to a System/360 mainframe. DescriptionThe total production run of the 1130 has been estimated at 10,000.[2] The 1130 holds a place in computing history because it (and its non-IBM clones) gave many people their first direct interaction with a computer. Its price-performance ratio was good and it notably included inexpensive, removable disk storage, with reliable, easy-to-use software that supported several high-level languages. The low price (from around $32,000 or $41,000 with disk drive)[1] and well-balanced feature set enabled interactive "open shop" program development. The IBM 1130 used the same electronics packaging, called Solid Logic Technology (SLT), used in System/360. It had a 16-bit binary architecture, as did later minicomputers like the PDP-11 and Data General Nova. The address space was 15 bits, limiting the 1130 to {{nowrap|32,768 16-bit}} words ({{nowrap|65,536 bytes}}) of memory. The 1130 used magnetic-core memory, which the processor addressed on word boundaries, using direct, indirect, and indexed addressing modes. ModelsIBM implemented five models of the 1131 Central Processing Unit, the primary processing component of the IBM 1130. The Model 1 through Model 5 described the core memory cycle time, as well as the model's ability to support disk storage. A letter A through D appended to the model number indicated the amount of core memory installed. IBM 1131 Central Processing Unit weighed about 760/1050 lb (345/477 kg).[3]
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 relied on the 1130 processor rather than internal logic to determine when to fire the print wheels as they rotated. Printers for the Model 4 ran more slowly, but the slower processor still could not keep up with it. The hardware manual disclosed 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 were disabled during this interval, even the end-of-card interrupt (level 4) from the 1442 card reader.
The IBM 1800 was a variant of the IBM 1130 for process control applications. It used hardware rather than core memory for the three index registers and featured two extra instructions (CMP and DCM) plus extra interrupt and I/O capabilities. It was a successor to the IBM 1710, as the IBM 1130 was a successor to the IBM 1620. The IBM 1500 was a multi-user educational system based around either an IBM 1130 or an IBM 1800. It supported up to 32 student work stations each with a variety of audio-visual capabilities. Other than these the 1130 had no compatible successor systems. The IBM System/7 was a process control and real-time system, and the IBM Series/1 was a general-purpose 16-bit minicomputer.
SoftwareTo maximize speed and conserve space, the operating system and compilers were written entirely in assembly language and employed techniques that are rare today, including intermixing code and data as well as self-modifying code. Much user programming was done in Fortran. The 1130 Fortran compiler could run on a machine with only 4,096 words of core—though the compiled program might not fit on such a machine. In this multi-pass compiler, each "phase" processed the entire source program and took it another step toward machine code. For example, the first phase read the source statements into memory, discarded comment lines, removed spaces except in text literals, concatenated continuation lines and identified labels. The compiler was available in a disk-resident version as well as on 8-channel punched paper tape or punched cards. The most widely used operating system for the 1130 was the Disk Monitor System Version 2 (DM2) introduced in 1967. DM2 was a single-task batch-oriented system. It required a system with at least 4 KB of core memory and one integrated 2310 disk drive for system residence. The Supervisor was tiny by modern standards, containing assorted system details such as first-level interrupt routines, called Interrupt Level Subroutines, plus the disk driver and routines to load the interpreter of job control commands and the card reader driver. Device drivers for other I/O devices required by a job were incorporated as part of the loading of that job, which might also include the replacement of the basic disk driver by a more advanced driver. During the execution of a job, only a resident monitor, called the Skeleton Supervisor, resided in memory. This Supervisor required just 1020 bytes, so a task's first available memory started with address /01FE (hexadecimal) or word 510. When the job ended or was aborted, the Supervisor loaded the Monitor Control Record Analyzer (MCRA) to read the job control for the next. While the job was running, the Supervisor was inactive. Aside from device drivers and interrupt processing all CPU time was entirely devoted to the job's activities. Other programs distributed as part of the operating system were a core dump utility, DUMP, and the Disk Utility Program, DUP. A Card/Paper Tape Programming System was available to support systems without disk. There was a hierarchy of device drivers: those ending in Z were for Fortran, such as DISKZ, while assembler programmers might use DISK0, and DISK1 was even faster at reading multiple disk sectors. But DISKZ started its sector addressing with the first available unused sector, while the others started with sector zero of the disk, making it easy for a Fortran programmer dabbling in assembler to inadvertently overwrite the bootstrap loader. Other programming languages available on the 1130 included
There was even an Algol compiler, written in French, so that "Debut ...Fin;" took the place of "Begin ... End;". All its messages were in French, so "Bonne compilation" was the goal. Eastern Michigan University developed a Fortran IV compiler for the 1130, known as Fortran-EMU, as an alternative to the Fortran IV (subset) compiler provided by IBM. It added many features, including the LOGICAL data type, enhanced diagnostics, and six-letter variable names. The Fortran-EMU compiler was distributed as a deck of punched cards in a disk image file format with all the remaining system area deleted, to prevent copying other modules that would normally reside on the same disk, such as the assembler or compilers. Oklahoma State University developed an ALGOL 68 compiler, written in ANSI Fortran 1966.[8][9][10]IBM also distributed a large library of programs, both IBM-supported (Type I and II) and unsupported (Type III and IV). Since the 1130 was aimed primarily at the scientific market, scientific and engineering programs predominated:
The 1130 also occupied a niche as a data processing machine for smaller organizations:
There was also special-purpose software:
Operating procedureThe enduring memories of the IBM 1130 may have resulted from its need for continual human intervention. It was usually occupied running "jobs" specified by a deck of punched cards. The human operator would load jobs into the card reader and separate them back into jobs for return, perhaps along with printed output, to the submitter. The operator would also have to watch the 1130 for evidence of a malfunctioning or stalled job and intervene by pressing the {{key press|INT REQ}} key on the keyboard to skip ahead to the start of the next job.[14] Marking the start of a job was a punched card that started with
Unlike the IBM 360, where a booting device could be selected from the system console, an IBM 1130 could only be "booted" (IPL'd: Initial Program Load) from an external device: a card reader or a paper tape reader.[15][16] The bootstrap procedure read one card from the card reader. The boot card contained binary code[17] to read the contents of sector zero of the disk drive, which in turn would handle the "operation complete" interrupt from the disk drive and perform additional disk reads to prepare the 1130 for the first punched-card job. The whole process took about a second to complete.
When the IBM 1130 was started, the Supervisor would still be in memory and probably intact, as core memory retains its state without power. If the operator concluded that a user program had stalled, the Supervisor could sense a key press to abort the program and skip ahead to the next // card. The Supervisor was not protected against modification by a badly written job, a case that might require that the operator reboot the 1130. Nor was there protection against writing to disk. If the copy of the system software on disk were modified, it could be restored by reloading it from about 4000 binary-coded punched cards (approximately two boxes). Disk organizationThe IBM 2310 disk drive stored sectors of 320 words (640 bytes) plus a one-word sector address. A cylinder consisted of two tracks on the top and bottom surfaces of the 2315, or of one platter on the 1316 disk pack used in the 2311. Each disk cylinder contained eight sectors. A sector was logically divided by the monitor into sixteen disk blocks of 20 words each (40 B); the disk block was the unit of allocation for files. The system distinguished between system cartridges, which contained the monitor and utilities along with user data, and nonsystem cartridges, which contained user data only. A system cartridge contained the cartridge id and the cold-start program (bootstrap code) in sector 0 followed by a communications area and the resident monitor in sectors one and two. Sectors three through five contained the System Location Equivalence Table (SLET)—a directory of all phases of all monitor programs. Other control information filled out the first track. The system area was followed by a fixed area containing system utilities, disk driver subroutines, IBM-supplied compilers and other control information. This area was mapped by a Fixed Location Equivalence Table (FLET) containing the file format, file name, and disk block count. The fixed area also contained the Location Equivalence Table (LET), in the same format as the FLET, mapping the following user area of the disk. The LET and FLET consisted of one entry per file on the disk giving the file's name and format information, its size in disk blocks, and its starting block number.[14] All disk files were contiguous disk blocks, thus there was no fragmentation. A program in need of working storage could use and modify named files, but could not expand them beyond their created size. Free space started after the last named file, and might be partially occupied by a temporary file, as the assembler or a compiler might produce. If a file was to be modified, the usual process was to use Disk space was at a premium, so program source files were normally kept as decks of cards. Users having larger requirements would arrange to have a disk of their own containing the operating system but only their files and would have to replace the "pool" system disk with theirs and restart the system when their turn at being operator came. A system with a second disk drive that could be devoted entirely to some user's code and data provided a great sense of spaciousness. Disk Utility Program (DUP)The Disk Utility Program (DUP) provided commands for transferring programs, subroutines and data. The "// DUP" card was followed by one or more cards:[18]
The operands, as was typical back then, had to be placed into fixed/assigned columns. Aside from the names of programs, subroutines or files, codes/values could be:
Programs could be converted to a more ready-to-use format with the STORECI command, which invoked Core Image Builder (DM2's counterpart to the 360's Linkage Editor). Alternatively, a program could go through this process each time it was to be run, and for infrequently used programs this was preferred in order to conserve disk space. Peripheral devicesDisk memory was used to store the operating system, object code, and data, but source code was kept on punched cards. The basic 1130 came with an IBM 2310 voice-coil actuated disk drive, called "Ramkit", from IBM's General Products Division in San Jose.[19]{{rp|497}} These read pizza-box-sized IBM 2315 single platter cartridges that held 512,000 words or 1,024,000 bytes (less than a 3.5" HD floppy's 1.44Mb or even the 5.25" HD floppy's 1.2Mb). The console typewriter used an IBM Selectric mechanism, which meant one could change the type by replacing a hollow, golf-ball sized type element. There was a special type element available for APL, a powerful array-oriented programming language using a special symbolic notation. A row of 16 toggle switches on the console typewriter could be individually tested from within programs, using the special Fortran statement Other available peripherals included:
To simplify the design of peripheral devices, these relied on the processor. The card reader had no memory buffers, but instead gave the CPU a level-zero (highest priority) interrupt after each individual column of the card had been read. If the CPU did not respond and store the twelve bits of data before another such interrupt indicated that the next column had been read, data would be lost. Similarly, the 1132 printer relied on software on the 1130. When a letter such as Other peripherals accepted text in a device-specific code convenient for its hardware. The CPU had to translate it to or from the EBCDIC code in which the CPU processed the text. Instruction set overviewInstructions had short (one-word) and long (two-word) formats. Most computational, load, and store instructions referenced one register (usually ACC) and a memory location. The memory location was identified, in the short format, by an 8-bit signed displacement from either the current address or one of the index registers; or in the long format, by a full 15-bit address, which could be indexed and specify indirection. Memory was addressed in units of words. The 1130 supported only single-precision and double-precision binary data natively (16 and 32 bits) stored in big-endian format. Standard- and extended-precision floating-point (32 and 48 bits) and decimal data were supported through the use of subroutines. Most conditional transfers were based on condition indicators as set by a preceding operation, usually reflecting the contents of ACC. Transfers could be by skip (which assumed that the next instruction was short) or by branch. Main Registers:IAR = Instruction Address RegisterACC = AccumulatorEXT = Extension RegisterXRx = Index Registers: x = 1,2,3 Implemented as memory words 1,2,3, not as hardware registers.Condition indicators+ Positive- NegativeZ ZeroO OverflowC CarryE Even1130 Instruction Set Mnemonics:LD = Load ACC STO = Store ACCLDD = Load Double (ACC & EXT) STD = Store Double (ACC & EXT)LDX = Load Index STX = Store IndexLDS = Load Status STS = Store StatusA = Add ACC AD = Add DoubleS = Subtract ACC SD = Subtract DoubleM = Multiply D = DivideAND = Boolean AND OR = Boolean ORXOR = Boolean Exclusive ORSLA = Shift Left ACC SLT = Shift Left ACC & EXTSLCA = Shift Left and Count ACC SLC = Shift Left and Count ACC & EXTSRA = Shift Right ACC SRT = Shift Right ACC & EXTRTE = Rotate Right ACC & EXTBSC = Branch or Skip on Condition (Modifier dependent) i.e. BP BNP BN BNN BZ BNZ BC BO BODBOSC - Branch Out or Skip Conditionally (alternate for BSC with bit 9 set) Exits current interrupt level.BSI = Branch and Store IARMDX = Modify Index and Skip (Increment IAR one if a sign change or becomes zero)WAIT = Halt NOP = No Operation (alternate for SLA 0)XIO = Execute I/O1800 Additional Instruction Mnemonics:CMP = Compare ACC DCM = Double Compare ACC & EXTEquivalent MnemonicsThe disk assembler introduced several mnemonics equivalent to existinginstructions intended to make the programmer's intent clearer:SKP - Skip on condition, equivalent to a short BSCB - Branch unconditionally, equivalent to BSC with no conditions specifiedBP - Branch Accumulator Positive, equivalent to BSC specifying '+' conditionBNP - Branch Accumulator not PositiveBN - Branch Accumulator NegativeBNN - Branch Accumulator not NegativeBZ - Branch Accumulator ZeroBNZ - Branch Accumulator not ZeroBC - Branch on CarryBO - Branch on OverflowBOD - Branch Accumulator OddMDM - Modify Memory, equivalent to unindexed long-format MDXXCH - Exchange Accumulator and Extension, equivalent to RTE 16Short instruction format (one 16 bit word): 1Bits 0...45678......5 OP---FTTDisp----OP is OperationF is format 0 = ShortTT is TagDisp is DisplacementLong instruction format (two 16 bit words): 1 1Bits 0...456789.....50..............5 OP---FTTIMod----Address---------OP is OperationF is format 1 = LongTT is TagI is Indirect bitMod is ModifierEffective Address Calculation (EA): F = 0 | F = 1, I = 0 | F = 1, I = 1 Direct Addressing| Direct Addressing| Indirect Addressing-------------------------------------------------------------------TT = 00 | EA = Displ + IAR | EA = Add | EA = C/AddTT = 01 | EA = Displ + XR1 | EA = Add + XR1 | EA = C/Add + XR1TT = 10 | EA = Displ + XR2 | EA = Add + XR2 | EA = C/Add + XR2TT = 11 | EA = Displ + XR3 | EA = Add + XR2 | EA = C/Add + XR3------------------------------------------------------------------- Disp = Contents of displacement field Add = Contents of address field of instruction C = Contents of location specified by Add or Add + XR
The lowest addresses of core memory had uses dictated either by the hardware or by convention:
ProgrammingSubprogramsThe 1130 had no hardware support for a stack. Most subprograms were called with the instruction BSI (Branch and Store IAR). This deposited the value of IAR (the return address) at the destination address and transferred control to destination+1. Subprograms returned 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[23] and the Scientific Data Systems SDS 920.[24] 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 '''I'''ndirect 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: The pseudo-operation CALL would typically be used. As shown, a subprogram's entry point was When SIMPL is called, the BSI instruction replaces Without extra arrangements to protect the return address, recursion would be impossible: If SIMPL called itself, or called a subprogram that called it, its original return address would be overwritten. Re-entrancy was 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 were placed in-line, SIMPL would modify its own return address so its final indirect branch returned beyond the parameters. Integer functions of a single integer would expect the parameter in the accumulator and would return their result there. Floating-point functions employed 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 meant that if a programming error led to SIMPL returning before the first time it was ever called, execution would jump to memory location 0. As mentioned above, it was 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. Linkage to library routinesFor subprograms that would be called many times (for example, subprograms for floating-point arithmetic), it was important to reduce the size of each call to one word. Such "library routines" used the LIBF protocol. It was more complex than the CALL protocol described in the previous section, but LIBF hid the complexity from the writer of the assembly-language program. Library routines were addressed through index register XR3. (Fortran subprograms would use index register XR1 for the addresses of parameters and the return address, but register XR2 was unused.) XR3 would be pointed to a sequence of three-word transfer vectors such that the first entry would be -128 words from XR3's value. The programmer would call the library routine using the The transfer vector was prepared by the linkage loader when it put together the program. A transfer vector to a library function named SIMPL took 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 left 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.
Suppose a LIBF-style call to SIMPL were at address 100. Then the return address would be 101, because The long jump transfers control to SIMPL. After the instruction at 300 stores XR1, the instruction at 301 is In the return sequence shown above, by the time control reaches RETN, the instruction there is
If SIMPL took parameters coded in-line following the BSI instruction, SIMPL could gain access to them with indexed addressing off XR1. The first could be obtained by A LIBF routine that declined to restore the original value of XR1 could omit the above steps and return with a simple The complexity of LIBF saves memory for subprograms that are frequently called.:[25]{{rp|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. Code modificationThe previous sections show that code and data were intermingled. It was common to modify the address fields of instructions and, in fact, to modify entire instructions. By the Fortran compilerThe Fortran compiler produced self-modifying code when generating code for any subprogram (subroutine or function) that had parameters. The compiler built a table of every location where the subprogram referenced one of its parameters, and compiled as the first instruction in the body of the subprogram a call to a subprogram called SUBIN that used 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 made these patches every time the subprogram was called. When a Fortran program called a subprogram, the addresses of any parameters appeared 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: The compiler instead used direct addressing. When SUBIN ran, it obtained the address of X and patched the instruction's address field to become: The advantages of SUBIN were as follows:
The disadvantages of SUBIN were the time it required to run and the memory required for the table of references. The size of this table was the sum of 5, the number of parameters, and the number of references; if this sum exceeded 511, compilation would fail. For subprograms with many references to a parameter, the author of the subprogram might copy the parameter into a local variable. By the userModifying entire instructions was a common technique. For example, although the 1130 had an OR instruction, the syntax of Fortran provided no way to write it. An integer function IOR could be defined, enabling logical OR to be part of a Fortran expression such as: The Fortran compiler would place the addresses of I and J in-line and expect the result in the accumulator. Using IOR(I,J) in a Fortran expression would compile 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 did not compute I or J at all. Instead, it replaced 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 did not return past the end of the four-word block (which it had just modified). Instead, it branched to the exact address from which it had been called originally. The BSI instruction was no longer there; what was now there was the two instructions it had just written. They combined the two integers with the machine-language OR instruction and left the result in the accumulator, as required. The call to IOR and the transformation of the four-word block happened at most once per program run. If the Fortran line illustrated above were executed again, it would run faster than it did the first time. Similar functions could be devised for other useful operations. A function that self-modified, as IOR does, could 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. Extended Precision1130 FORTRAN offered two floating point formats: a 32-bit "standard precision" format and a 40-bit "extended precision" format. Standard precision format contained a 24-bit two's complement significand while extended precision utilized a 32-bit two's complement significand. The latter format could make full use of the cpu's 32-bit integer operations. The characteristic in both formats was an 8-bit field containing the power of two biased by 128. Floating-point arithmetic operations were performed by software, and double precision was not supported at all. The extended format occupied three 16-bit words, with the extra space simply ignored.[26] The "*EXTENDED PRECISION" compiler option card told the FORTRAN compiler to use 40 bits instead of 32 bits for Floating Point data. Large Fortran programsData to be manipulated and the instructions that manipulated them had to reside together in core memory. The amount of installed memory (from 4,096 to 32,768 words) was a key limitation. Fortran provided several techniques to write large programs despite this limitation.
Fortran let any subprogram be designated as "LOCAL" (Load-on-Call). Each LOCAL subprogram was an overlay; it would be part of the disk-resident executable program but would only be loaded into core memory (if not already there) during the time it was 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 could invoke another, either directly or through intermediary subprograms.
An entire Fortran program could 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 would be started by
Programs, such as Fortran programs, resided at low core memory addresses (just above the Supervisor). Fortran allocated space at the highest addresses for any variables and arrays declared COMMON. If a follow-on phase of the program contained a corresponding COMMON declaration, then information in this common area could 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 shared data between phases; lower-memory COMMON variables could 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. Programming examplesThe examples can be executed on the IBM 1130 emulator available at IBM 1130.org. Sample Assembler program deckThe 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 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 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 This example contains no code to decide when to stop. A more complete program would check for cards that begin with Asynchronous I/O and performanceThe 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 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. Sample Fortran IV program deckThe following listing shows a card deck that compiles and runs a Fortran program and Fortran subroutine for the IBM 1130 when running DM2. // JOB// FOR*LIST SOURCE PROGRAM*ONE WORD INTEGERSC------------------------------------------------------- C COMPUTE THE CRITICAL VALUES FOR A QUADRATIC EQNC 0=A*X**2+B*X+CC RETURNS DISCRIMINANT, ROOTS, VERTEX, FOCAL LENGTH, FOCAL POINTC X1 AND X2 ARE THE ROOTSC------------------------------------------------------- SUBROUTINE QUADR(A,B,C,DISCR,X1,X2,VX,VY,FL,FPY) REAL A,B,C,DISCR,X1,X2,VX,VY,FL,FPYC DISCRIMINANT, VERTEX, FOCAL LENGTH, FOCAL POINT Y DISCR = B**2.0 - 4.0*A*C VX = -B / (2.0*A) VY = A*VX**2.0 + B*VX + C FL = 1.0 / (A * 4.0) FPY = VY + FL FL = ABS(FL)C COMPUTE THE ROOTS BASED ON THE DISCRIMINANT IF(DISCR) 110,120,130C -VE DISCRIMINANT, TWO COMPLEX ROOTS, REAL=X1, IMG=+/-X2110 X1 = -B / (2.0*A) X2 = SQRT(-DISCR) / (2.0*A) RETURN C ZERO DISCRIMINANT, ONE REAL ROOT120 X1 = -B / (2.0*A) X2 = X1 RETURNC +VE DISCRIMINANT, TWO REAL ROOTS130 X1 = (-B + SQRT(DISCR)) / (2.0*A) X2 = (-B - SQRT(DISCR)) / (2.0*A) RETURNCC NEXT STORE SUBROUTINE ON DISK USING DUP END// DUP*DELETE QUADR*STORE WS UA QUADR// JOB// FOR*LIST SOURCE PROGRAM *IOCS(CARD,1132 PRINTER) *ONE WORD INTEGERS C------------------------------------------------------- C PROCESS DATA CARDS WITH A,B,CC UNTIL A=0C------------------------------------------------------- DATA ICARD,IPRT /2,3/ REAL A,B,C REAL DISCR,XR1,XR2,VX,VY,FL,FPY WRITE(IPRT,901)901 FORMAT(' ------------------------------------------------------')C READ A B C, IF A=0 THEN EXIT100 READ(ICARD,801)A,B,C801 FORMAT(3F8.3)C EXIT WHEN A IS ZERO IF (A) 110,9000,110C PRINT A B C 110 WRITE(IPRT,902)A,B,C902 FORMAT(' QUADRATIC A=',F8.3,' B=',F8.3,' C=',F8.3)C COMPUTE AND PRINT THE CRITICAL VALUES CALL QUADR(A,B,C,DISCR,XR1,XR2,VX,VY,FL,FPY) WRITE(IPRT,903) DISCR903 FORMAT(' DISCRIMINANT=',F9.4) WRITE(IPRT,904) VX,VY904 FORMAT(' VERTEX X=',F9.4,' Y=',F9.4) WRITE(IPRT,905) FL905 FORMAT(' FOCAL LENGTH=',F9.4) WRITE(IPRT,906) VX,FPY906 FORMAT(' FOCAL POINT X=',F9.4,' Y='F9.4) IF (DISCR) 120,130,140C -VE DISCRIMINANT, TWO COMPLEX ROOTS120 WRITE(IPRT,913) XR1, XR2913 FORMAT(' COMPLEX ROOTS =(',F9.4,' +/-',F9.4,'I)') GO TO 200 C ZERO DISCRIMINANT, ONE REAL ROOT130 WRITE(IPRT,912) XR1912 FORMAT(' ROOT X =',F9.4) GO TO 200C +VE DISCRIMINANT, TWO REAL ROOTS140 WRITE(IPRT,911) XR1, XR2911 FORMAT(' ROOTS X1=',F9.4,' X2=',F9.4)C --- GO TO 200C END OF QUAD200 WRITE(IPRT,901) GO TO 100C END OF PROGRAMC DATA FOLLOWS XEQ CARD9000 CALL EXIT END// XEQ+001.000+000.000+000.000+001.000+002.000+003.000+002.000+002.000+000.000+002.000+000.000-004.000+000.500+000.000-004.000+000.250+002.000-002.000-004.000+000.000-004.000+002.730-007.200-003.750+000.000+000.000+000.000 Sample APL\\1130 sessionThe 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. Influence of the 1130
... I pounded the doors at the local IBM sales office until a salesman took pity on me. After we chatted for a while, he handed me a Fortran [manual]. I'm sure he gave it to me thinking, "I'll never hear from this kid again." I returned the following week saying, "This is really cool. I've read the whole thing and have written a small program. Where can I find a computer?" The fellow, to my delight, found me programming time on an IBM 1130 on weekends and late-evening hours. That was my first programming experience, and I must thank that anonymous IBM salesman for launching my career. Thank you, IBM.
The system was an IBM 1130 computer, a machine the size of a desk with 8 KB of main memory, a 512 KB disk drive, a Teletype CX paper tape reader and BRPE paper tape punch, and a Photon 713 photomechanical typesetter. The assignment was my first experience with managing a machine-readable document database: I learned to roll the punched paper tape carefully so that it could be stored neatly in cylindrical waste paper baskets.
1130s today
ApocryphaSpeculation on why the product was given the number 1130 centered on the following possibilities:
Others have speculated that the existence of the IBM 1130 explains why no computer designated "11/30" ever appeared in the PDP-11 family of machines.[44] See also
References1. ^1 {{cite news |url=http://www.ibm1130.net/1130Release.html |title=IBM INTRODUCES POWERFUL SMALL COMPUTER |publisher=IBM |author=C. G. Francis, Director of Information, Data Processing Division |location=White Plains, New York |date=February 11, 1965}} 2. ^{{cite interview | last = Utley | first = Brian | title = Guest speaker: Brian Utley | url = http://ibm1130.org/party/v03 | format = MP3 |date=Jan 2005 | page = | pages = | accessdate = 2012-01-02 }} 3. ^760 lb: models 1A, 1B, 2A, 2B, 4A and 4B 1050 lb: models 1C, 1D, 2C, 2D, 3B, 3C, 3D, 5B, 5C and 5D*{{cite web |title=IBM 1130 documents |url=http://www.bitsavers.org/pdf/ibm/1130/ |website=www.bitsavers.org|at=fe/GA26-5914-8_1130_Installation_Manual_Physical_Planning_Dec71.pdf, pp. 10-11}} 4. ^{{cite journal|url=http://www.vector.org.uk/archive/v223/APL_1130.htm|title=How We Got To APL\\1130|author=Larry Breed|authorlink=Lawrence M. Breed|journal=Vector (British APL Association)|volume=22|issue=3|date=August 2006|issn=0955-1433 }} 5. ^for which there was an IBM compiler 6. ^SL/1: references to Student Language/One, Student Language/1 and Subset Language/1 exist 7. ^an IBM Program Product 8. ^Hedrick, G.E.; Robertson, Alan, "The Oklahoma State ALGOL 68 Subset Compiler". 1975 International Conference on ALGOL 68. Stillwater, OK, June 10–12, 1975. 9. ^Hedrick, G. E., "ALGOL68 instruction at Oklahoma State University", ACM SIGCSE Bulletin – Special issue eighth technical symposium on computer science education Homepage, Volume 9 Issue 3, Aug 1977, ACM New York, NY, USA 10. ^McJones, Paul, "Algol 68 implementations and dialects", Software Preservation Group, Computer History Museum 11. ^{{cite book|last1=IBM Corporation|title=1130 Statistical System (1130-CA-06X) User's Manual|date=1967|url=http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/1130/statisticalSystem/H20-0333-1_1130_Statistical_System_Users_Manual_1967.pdf|accessdate=Feb 8, 2015}} 12. ^{{cite book|last1=IBM Corporation|title=IBM 1130 Remote Job Entry Work Station Program Program Logic Manual|date=1968|url=http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/1130/program_libr/Y30-1001-0_RJE_PLM_Jun68.pdf|accessdate=Feb 8, 2015}} 13. ^{{cite book|last1=IBM Corporation|title=IBM 1130 Typesetting System (RPQ)|date=1967|url=http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/1130/program_libr/GA26-3531-0_1130_Typesetting_System_1967.pdf|accessdate=Feb 8, 2015}} 14. ^1 {{cite book|last1=IBM Corporation|title=IBM 1130 Disk Monitor System, Version 2, Programmer's and Operator's Guide|date=May 1972|url=http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/1130/monitor/C26-3717-9_1130_1130_Disk_Monitor_System_Version_2_Programming_and_Operators_Guide_May72.pdf|accessdate=Feb 6, 2015}} 15. ^{{cite web|url=http://ed-thelen.org/comp-hist/vs-ibm-1130.html|title=This artifact|accessdate=2017-02-21}} 16. ^Quote: "Our 1130 has a 2315, 1/2 million-word disk cartridge unit on the right side, behind the door. The paper tape reader was probably primarily used for booting, instead of the large, 300 cards/min 1442 card reader." 17. ^{{cite book|url=http://media.ibm1130.org/1130-102-ocr.pdf|title=Systems Reference Library IBM 1130 Functional Characteristics}} Page 136 of the Functional Characteristics, Figure 40, shows how each of the 12 holes on a punched card fill the 16 bits of a memory word, when doing an IPL (Initial Program Load), using "Load Mode Read." 18. ^http://www.ibm1130.net/DM2/MonitorPrograms.html#dupcontrecords 19. ^1 {{cite book |title= IBM's 360 and early 370 systems |author1= Emerson W. Pugh |author2= Lyle R. Johnson |author3= John H. Palmer |publisher= MIT Press |year= 1991 |isbn= 978-0-262-16123-7 |url= https://books.google.com/books?id=MFGj_PT_clIC }} 20. ^{{cite book |url=http://media.ibm1130.org/E0004.pdf |accessdate=2009-08-10 |series= |edition=First |title=IBM 1130 Custom Feature Description – Attachment Channel RPQ Number 831552, Form A26-1579-0 |author= |first= |last= |authorlink= |date= October 1968 |location=San Jose, California |work=IBM System Reference Library |publisher=IBM Corporation |pages= |doi= }} 21. ^http://www.ibm1130.net/functional/OMPR.html 22. ^{{cite web|last=IBM Corporation|title=IBM Archives: DPD Chronology (page 4)|url=http://www-03.ibm.com/ibm/history/exhibits/dpd50/dpd50_chronology4.html|accessdate=10 Aug 2011}} 23. ^{{cite book|last1=Hewlett-Packard|title=2100A Computer Reference Manual|date=December 1971|page=18|url=http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/21xx/02100-90001_2100refManDec71.pdf|accessdate=August 5, 2016}} 24. ^{{cite book|last1=Scirntific Data Systems|title=920 Computer Reference Manual|page=17|url=http://bitsavers.informatik.uni-stuttgart.de/pdf/sds/9xx/920/SDS5002_920_RefMan.pdf|accessdate=August 5, 2016}} 25. ^{{cite book|last1=IBM Corporation|title=IBM 1130 Assembler Language|date=1968|url=http://bitsavers.trailing-edge.com/pdf/ibm/1130/lang/C26-5927-4_1130_Assember_Upd_Jun68.pdf|accessdate=Feb 6, 2015}} 26. ^{{cite book |title=IBM 1130 Subroutine Library 9th ed |year=1974 |publisher=IBM Corporation |pages=93 |url=http://media.ibm1130.org/1130-037-ocr.pdf |doi= }} 27. ^{{cite web|url=http://mail.computerhistory.org/pipermail/inforoots/2006-October/001138.html|title=Origin of the IBM 1130 Name|first=Brian|last=Utley|date=2006-10-30|accessdate=2007-01-16}} 28. ^{{cite web|url=http://www-106.ibm.com/developerworks/library/i-booch/ |title=Grady Booch polishes his crystal ball|first=Grady|last=Booch|authorlink=Grady Booch|date=2003-04-03|publisher=IBM |accessdate=2007-01-16}} 29. ^{{cite web|url=http://www.ddj.com/dept/architect/184406382|title=Thoughts on Language Design -- New challenges require new solutions|first=Guy L., Jr.|last=Steele|authorlink=Guy L. Steele, Jr.|date=2005-11-24|publisher=Dr. Dobb's Journal|accessdate=2006-01-16}} 30. ^{{cite web|url=http://www.ccil.org/jargon/jargon.html |title=Confessions of a Happy Hacker |first=Guy L., Jr. |last=Steele |authorlink=Guy L. Steele, Jr. |accessdate=2006-01-16 |archiveurl=https://web.archive.org/web/20070203031636/http://www.ccil.org/jargon/jargon.html |archivedate=2007-02-03 |deadurl=yes |df= }} 31. ^{{cite web|url=http://www.forth.com/resources/evolution/evolve_0.html|title=The Evolution of Forth|first=Elizabeth|last=Rather |author2=Colburn, Donald |author3=Moore, Charles|date=March 1993|accessdate=2007-01-16}} 32. ^{{cite web|url=http://www.danbricklin.com/log/2002_08_23.htm|title=Memories while visiting the Bay Area and the Computer History Museum|date=2002-08-23|first=Dan|last=Bricklin|authorlink=Dan Bricklin|accessdate=2007-01-16}} 33. ^{{cite web|url=http://www.bigear.org/oldseti.htm|title=SETI in the 1970s|first=Bob|last=Dixon|date=2005-08-13|publisher=The Big Ear|accessdate=2007-01-16}} 34. ^{{cite web|url=http://www.sgmlsource.com/history/roots.htm|title=The Roots of SGML -- A Personal Recollection|first=Charles|last=Goldfarb|authorlink=Charles Goldfarb|year=1996|accessdate=2007-01-16}} 35. ^Kay, Alan C., "The Reactive Engine", Ph.D. dissertation, University of Utah, 1969."The graphics display routines, character generator and editor ran for a year on an IBM 1130 computer with a “home-brew” interface. Unfortunately, the 1130 was straining to just act as a glorified display buffer, and none of the algorithmic routines were implemented." 36. ^{{cite web|url=http://www.eric.ed.gov/fulltext/ED070289.pdf|title=The Use of Computers in Instruction in Secondary Schools|first=Warren|last=Koch|year=1972|accessdate=2014-08-06}} 37. ^{{cite web|url=http://www.cpushack.com/2016/10/16/signetics-2650-an-ibm-on-a-chip/|title=Signetics 2650: An IBM on a Chip|publisher=CPU Shack|date=16 October 2016|accessdate=25 October 2016}} 38. ^{{cite web|title=IBM 1130|url=http://www.aconit.org/spip/spip.php?rubrique6|website=ACONIT|language=French|accessdate=July 11, 2016}} 39. ^{{cite web|title=Artifact Details:BM 1130 model|url=http://www.computerhistory.org/collections/catalog/102689999|website=Computer History Museum|accessdate=July 11, 2016}} 40. ^{{cite web|last1=Wyss|first1=Oscar|url=http://www.cosecans.ch/home/oscar.e.wyss/galerie.html|title=Website von Oscar E. Wyss |website=COSECANS|language=German|accessdate=July 11, 2016}} 41. ^{{cite web|title=IBM 1130 system restoration during 2011|url=http://www.tnmoc.org/news/current-projects/ibm-1130-system-restoration-during-2011|website=The National Museum of Computing|accessdate=July 11, 2016}} 42. ^{{cite web|title=IBM 1130|url=http://computermuseum.informatik.uni-stuttgart.de/dev_en/ibm1130/ibm1130.html|website=Computermuseum der Fakultät Informatik|accessdate=July 11, 2016}} 43. ^{{cite web|last1=Claunch|first1=Carl|title=Rescue 1130|url=http://rescue1130.blogspot.com/|accessdate=July 11, 2016}} 44. ^PDP-11/20 and /15 External links{{Commons category}}
2 : IBM minicomputers|Magnetic Core Memory computers |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 随便看 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。