Difference between revisions of "IBM System/360"
m (Add virtual addr size to infobox) |
(Link to coming 'IBM I/O channel' article) |
||
| (12 intermediate revisions by the same user not shown) | |||
| Line 24: | Line 24: | ||
}} | }} | ||
| − | The '''System/360''' is a ground-breaking family of [[mainframe]] computers introduced by [[International Business Machines|IBM]]. In addition to making 8-[[bit]] [[byte]]s the standard, its most notable contribution was the introduction of the idea of a program | + | The '''System/360''' is a ground-breaking family of [[mainframe]] computers introduced by [[International Business Machines|IBM]]. In addition to making 8-[[bit]] [[byte]]s the standard, its most notable contribution was the introduction of the idea of a [[program compatible]] family of computers, across a fairly broad performance range. As a result, it dominated the computer world until the rise of [[minicomputer]]s. |
| − | It ran a variety of software, such as [[MVS]]. | + | It ran a variety of software, such as the [[MVS]] [[operating system]]. |
The System/360 was supplanted by the [[IBM System/370]]. | The System/360 was supplanted by the [[IBM System/370]]. | ||
== History == | == History == | ||
| − | Before the IBM 360, in 1959 - 1964, IBM provided four major product lines of computers. They had small business computers like the 1401, large business computers like the 7070, small scientific computers like the 1620, and large scientific machines like the [[IBM 7094|709x]] series. All were incompatible, and so 4 complete sets of | + | |
| + | Before the IBM 360, in 1959-1964, IBM provided four major product lines of computers. They had small business computers like the [[IBM 1401|1401]], large business computers like the [[IBM 7070|7070]], small scientific computers like the [[IBM 1620|1620]], and large scientific machines like the [[IBM 7094|709x]] series. All were incompatible, and so 4 complete sets of operating systems and development tools were being supported simultaneously. This was becoming a problem as manufacturers were providing more and more complex software. So, they came up with the idea of ONE compatible computer product line that would satisfy both business and scientific computing users. The name System 360 came from supporting the full circle of computing needs. | ||
IBM literally bet the company on the success of the 360. If it had been a flop, they very well could have gone out of business. But, it was a VERY well thought-out bet, and of course, history shows that it was one of the most successful products of all time. They DID have some serious trouble getting machines into user's hands, however. | IBM literally bet the company on the success of the 360. If it had been a flop, they very well could have gone out of business. But, it was a VERY well thought-out bet, and of course, history shows that it was one of the most successful products of all time. They DID have some serious trouble getting machines into user's hands, however. | ||
| Line 39: | Line 40: | ||
The second issue was software, most specifically operating system software. There were two lower-level systems for the smallest machines, Disk OS and Tape OS. For machines of the 360/50 class, there was OS/360 MFT, which had memory partitions that were set by the operators. And, then, there was the top of the line system, OS/360 MVT, which could dynamically alter the [[main memory]] partitions based on the mix of jobs to be run. | The second issue was software, most specifically operating system software. There were two lower-level systems for the smallest machines, Disk OS and Tape OS. For machines of the 360/50 class, there was OS/360 MFT, which had memory partitions that were set by the operators. And, then, there was the top of the line system, OS/360 MVT, which could dynamically alter the [[main memory]] partitions based on the mix of jobs to be run. | ||
| − | + | The MVT system was so complicated that IBM was VERY late in delivering it. It led to some books such as Fred Brooks' "The Mythical Man-Month" which described some of the issues in scaling up very large software projects. | |
| + | |||
| + | == Specifications == | ||
| − | + | * The 360 is a 32-bit machine; | |
| − | *The 360 is a | + | * 16 general purpose 32-bit [[register]]s, 0 to 15 (usually Equated to the labels "R0" through "R15") |
| − | *16 general purpose 32-bit [[register]]s, 0 to 15 (usually Equated to the labels "R0" through "R15") | + | * 4 [[floating point]] 64-bit registers numbered 0, 2, 4 and 6; and |
| − | *4 [[floating point]] 64-bit registers numbered 0, 2, 4 and 6 | + | * a [[Processor Status Word|Program Status Word]] (PSW); it contains the privileged bit, the [[program counter]], and the memory [[protection key]]. |
| − | *a [[Processor Status Word|Program Status Word]] (PSW) | ||
The 360 is a [[big-endian]] machine, with values stored as high to low. | The 360 is a [[big-endian]] machine, with values stored as high to low. | ||
| − | The 360 instruction set had 3 major classes of [[instruction]]s, register to register, specified in a 16-bit field; register to indexed storage, specified in 32 bits; and storage to storage, specified in 48 bits. There was a 2-bit instruction length field in the op-code to specify the length of the instruction. The op-code always occupied 8 bits. | + | Other than the model /20, all 360's used I/O processors called [[channel]]s, to which all [[peripheral]]s were attached via [[IBM I/O channel]]s. On lower machines (/30 through the /50) the channels were emulated in [[microcode]]. On higher machines (/65 and up) the channels were separate boxes directly connected to the main memory. |
| + | |||
| + | The 360 [[instruction set]] had 3 major classes of [[instruction]]s, register to register, specified in a 16-bit field; register to indexed storage, specified in 32 bits; and storage to storage, specified in 48 bits. There was a 2-bit instruction length field in the op-code to specify the length of the instruction. The op-code always occupied 8 bits. | ||
| − | The register to indexed storage instruction had a 4-bit field to specify the base register, a 4-bit field for the [[index register]] and a 12-bit field for the offset. The contents of the base register, the index register and the offset were added to produce the physical address of the operand. If the base register was zero, then it was not added to the effective address. | + | The register to indexed storage instruction had a 4-bit field to specify the [[base register]], a 4-bit field for the [[index register]] and a 12-bit field for the offset. The contents of the base register, the index register and the offset were added to produce the physical address of the operand. If the base register was zero, then it was not added to the effective address. |
The storage to storage instructions specified two storage locations, and were used for instructions that moved byte strings, compared byte strings and translated byte strings to different character encodings. | The storage to storage instructions specified two storage locations, and were used for instructions that moved byte strings, compared byte strings and translated byte strings to different character encodings. | ||
| + | |||
| + | ===Memory management=== | ||
In the initial models, [[memory management]] was provided with protection keys. Each 2K-byte block of memory had a 4-bit register which held a key value; the PSW contained the key of the currently running code, and writes to a given block were only allowed when they matched. | In the initial models, [[memory management]] was provided with protection keys. Each 2K-byte block of memory had a 4-bit register which held a key value; the PSW contained the key of the currently running code, and writes to a given block were only allowed when they matched. | ||
| + | |||
| + | A feature of the 360 instruction set was that all object program files were relocatable, due to the use of the base register. The OS could load a program at any place in [[main memory]], and then set the base register to the beginning of that memory partition. But, a limitation of that was that once a program started running, it began to use physical addresses for data, and the return address from a [[subroutine]] call. Therefore, once started, the program could not be relocated to a different memory area. | ||
| + | |||
| + | IBM did not adequately think out all the implications of the interaction of this with [[swapping]], and with lots of programs coming and going in random-sized memory blocks, memory fragmentation could build up, turning memory into a checkerboard of unused space, with lots of little unused gaps between blocks that were in use. There were tricks to avoid this, like requiring all jobs to occupy regions with integral relationships (like 50 K, 100 K, 150 K, 200 K, etc). | ||
| + | |||
| + | One of the designer, Gerald Blaauw, had initiallly proposed adding a mechanism, later nicknamed the 'Blaauw Box', which apparently added a special (invisible to the program) base register that would be added to all memory references, so that the program could be fooled into seeing itself as always running at location zero. Thus, the program could be moved around in memory as needed, after being swapped out and back in. | ||
| + | |||
| + | That was originally proposed as standard mechanism for the 360's, but the decision was made not to add it. IBM then proposed it as a special 'add-on' for organizations which wanted [[time-sharing]] on 360's, but the clients turned it down because they wanted [[virtual memory]], not just relocation. | ||
| + | |||
| + | Virtual memory was finally added to one model in the line, the Model 67. | ||
==Models== | ==Models== | ||
| Line 106: | Line 122: | ||
# ''US Government only'' | # ''US Government only'' | ||
| − | The 360/20 was a "half-size" 360, it only implemented 16-bit size operations, and had only 8 general purpose registers, so | + | The 360/20 was a "half-size" 360, it only implemented 16-bit size operations, and had only 8 general purpose registers, so that is not included as a real member of the 360 series. |
| − | |||
| − | |||
| − | + | Most 360's used microcode, but the 360/44 did not, and also 360/91 and /95 and /195 (which were [[superscalar]] machines and were not micro-coded). | |
| − | The 360/30 internally had 8-bit wide memory and 8-bit data paths, but emulated the full 32-bit instruction set. It was rated at 30K to 40K instructions/second, depending on instruction mix. The processor was so slow that when I/O was operating, the CPU was totally dedicated to handling the channel operation. The 360/30 had the local storage (register set) in a separately addressed section of main | + | The 360/30 internally had 8-bit wide memory and 8-bit data paths, but emulated the full 32-bit instruction set. It was rated at 30K to 40K instructions/second, depending on instruction mix. The processor was so slow that when I/O was operating, the CPU was totally dedicated to handling the channel operation. The 360/30 had the local storage (register set) in a separately addressed section of main memory. |
The 360/40 internally had 16-bit memory and data paths, and was rated at about 80K instructions/second. | The 360/40 internally had 16-bit memory and data paths, and was rated at about 80K instructions/second. | ||
| Line 120: | Line 134: | ||
The 360/40 and 360/50 also used a separate [[core memory|core]] storage for the registers. | The 360/40 and 360/50 also used a separate [[core memory|core]] storage for the registers. | ||
| − | The 360/65 had 64-bit memory, and a 56-bit [[Arithmetic logic unit|ALU]], so it could process double-precision floating point in one cycle. It allowed pairs of identical memory units to be [[interleaved]], increasing performance even more. Memory [[cycle time]] was 640 ns, pretty fast for its time. | + | The 360/65 had 64-bit memory, and a 56-bit [[Arithmetic logic unit|ALU]], so it could process double-precision floating point in one cycle. It allowed pairs of identical memory units to be [[memory interleaving|interleaved]], increasing performance even more. Memory [[cycle time]] was 640 ns, pretty fast for its time. |
It was possible to connect two /65s to one memory system to create a [[multi-processor]] system, although it was not twice as fast as a single CPU, due to memory interference. It did save some cost as you did not have to duplicate memory and peripherals. A special version of the OS/MVT system called MP65 was developed for the dual processor system, but a lot of installations used it on a single processor because it had enhanced error recovery. The /65 was rated over 600 K IPS. | It was possible to connect two /65s to one memory system to create a [[multi-processor]] system, although it was not twice as fast as a single CPU, due to memory interference. It did save some cost as you did not have to duplicate memory and peripherals. A special version of the OS/MVT system called MP65 was developed for the dual processor system, but a lot of installations used it on a single processor because it had enhanced error recovery. The /65 was rated over 600 K IPS. | ||
| − | A variant of the 360/65 was the 360/67, which added [[ | + | A variant of the 360/65 was the 360/67, which added [[segment]]ion and virtual memory, as well as optional extended [[virtual address]]ing (normally 24 bits, the option extended them to 32 bits). A segment (specified by the high bits of the virtual address) could be up to 1Mbyte; they contained up to 256 4Kbyte pages. This mechanism, named "Dynamic Address Translation", was the basis of the DAT later added to all the models of the follow-on System/370. |
| − | + | The Model 67 too was available as a two-CPU system. It was also capable of [[virtualization]] (the first machine to do so, apparently), and the [[CP operating system]] (the ancestor of IBM's [[VM operating system]]) was developed for it to take advantage of this. | |
The 360/75 was the top end of the classic 360 machines. | The 360/75 was the top end of the classic 360 machines. | ||
| Line 132: | Line 146: | ||
All of these models were built with SLT (Solid Logic Technology) a hybrid technology where thin film resistors were deposited on 1/2" square ceramic substrates, then thick film silver conductors were deposited, and finally discrete transistor and diode die were flip-chip bonded to the traces. | All of these models were built with SLT (Solid Logic Technology) a hybrid technology where thin film resistors were deposited on 1/2" square ceramic substrates, then thick film silver conductors were deposited, and finally discrete transistor and diode die were flip-chip bonded to the traces. | ||
| − | This was pretty low-density technology, generally there were 2 2-input gates per SLT module, consisting of 4 diodes, 4-6 resistors and 2 transistors. IBM did not use [[flip-flop]]s, but they made D- | + | This was pretty low-density technology, generally there were 2 2-input gates per SLT module, consisting of 4 diodes, 4-6 resistors and 2 transistors. IBM did not use [[flip-flop]]s, but they made [[flip-flop#D flip-flop|D-latch]]es for registers. These occupied 2 1/2 SLT modules for one D-latch. |
The 360/85 was a prototype for the 370/165, which was a very similar machine. It was the first IBM machine to use a [[cache]] memory ("storage buffer") in static RAM, as well as the first of their commercial machines to use monolithic [[integrated circuit]]s (called MST for Monolithic Solid Technology). | The 360/85 was a prototype for the 370/165, which was a very similar machine. It was the first IBM machine to use a [[cache]] memory ("storage buffer") in static RAM, as well as the first of their commercial machines to use monolithic [[integrated circuit]]s (called MST for Monolithic Solid Technology). | ||
| Line 139: | Line 153: | ||
== Emulation == | == Emulation == | ||
| − | I don't think there is any direct S/360 | + | |
| + | I don't think there is any direct S/360 emulator out there... However I'm pretty sure that [[Hercules]] will run System 360 software, as the 370 is upwards compatible with the 360. | ||
==Further reading== | ==Further reading== | ||
* Emerson W. Pugh, Lyle R. Johnson, John H. Palmer, "IBM's 360 and Early 370 Systems", MIT Press, 1991 | * Emerson W. Pugh, Lyle R. Johnson, John H. Palmer, "IBM's 360 and Early 370 Systems", MIT Press, 1991 | ||
| + | * G. M. Amdahl, G. A. Blaauw, F. P. Brooks, Jr., [https://www.ece.ucdavis.edu/~vojin/CLASSES/EEC272/S2005/Papers/IBM360-Amdahl_april64.pdf ''Architecture of the IBM System/360''], IBM Journal, April 1964 | ||
| + | * G. A. Blaauw, F. P. Brooks, Jr., [https://www.ece.ucdavis.edu/~vojin/CLASSES/EEC272/S2005/Papers/IBMSystem360-Blaauw_64.pdf ''The Structure of SYSTEM/360: Part I - Outline of the logical structure''], IBM Systems Journal, Vol. 3, No. 2, 1964 | ||
| + | * David Gifford, Alfred Spector, Richard Case, Andris Padegs, [https://www.ece.ucdavis.edu/~vojin/CLASSES/EEC272/S2005/Papers/IBM360-370_ACM-87.pdf ''Case Study: IBM's System/360-370 Architecture''], Communications of the ACM, Vol. 30, No. 4, April 1987 | ||
| + | * Andris Padegs, [https://www.ece.ucdavis.edu/~vojin/CLASSES/EEC272/S2005/Papers/Padegs-IBM360-sep81.pdf ''System/360 and Beyond'']. IBM Journal of Research and Development, Vol. 25, No. 5, September 1981 | ||
| + | |||
| + | ==See also== | ||
| + | |||
| + | * [[CP operating system]] | ||
| − | ==External | + | ==External links== |
| − | * [http://www-03.ibm.com/ibm/history/exhibits/mainframe/ | + | * [https://bitsavers.org/pdf/ibm/360/ 360] - documentation at [[Bitsavers]] |
| + | ** [http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf IBM System/360 Principles of Operation] | ||
| + | * [http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html System/360 Dates and characteristics] | ||
| + | ** [https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2091.html IBM Archives System/360 Model 91] | ||
| + | * [https://web.archive.org/web/20190615175558/http://archive.michigan-terminal-system.org/discussions/blaauw-box-vs-dat-box-on-the-s-360-67 Blaauw box vs. DAT box on the S/360-67] | ||
| + | * [http://www.quadibloc.com/comp/pan04.htm The IBM System/360 Saga] | ||
| + | * [https://www.righto.com/2019/04/iconic-consoles-of-ibm-system360.html Iconic consoles of the IBM System/360 mainframes] | ||
| + | * [https://www.righto.com/2022/01/ibm360model50.html Simulating the IBM 360/50 mainframe from its microcode] | ||
| + | * [https://www.righto.com/2019/11/tros-how-ibm-mainframes-stored.html TROS: How IBM mainframes stored microcode in transformers] | ||
| − | [[Category:IBM Mainframes]] | + | [[Category: IBM Mainframes]] |
| + | [[Category: 32-bit Computers]] | ||
Latest revision as of 13:58, 23 January 2024
| System/360 | |
| Manufacturer: | International Business Machines |
|---|---|
| Year Announced: | April 7, 1964 |
| Year First Shipped: | April, 1965 |
| Year Discontinued: | October, 1977 |
| Form Factor: | mainframe |
| Word Size: | 32 bits |
| Design Type: | microcoded (most models) |
| Clock Speed: | 1 μsec (Model 30) 60 nsec (Model 91) |
| Memory Speed: | 2 μsec (Model 30) 780 nsec (Model 91) |
| Virtual Address Size: | 24 bits (optionally 32 on the Model 67) |
| Memory Management: | protection keys (most models) |
| Operating System: | OS/360, MVS |
| Predecessor(s): | IBM 1401, IBM 1620, IBM 7070, IBM 7094 |
| Successor(s): | IBM System/370 |
The System/360 is a ground-breaking family of mainframe computers introduced by IBM. In addition to making 8-bit bytes the standard, its most notable contribution was the introduction of the idea of a program compatible family of computers, across a fairly broad performance range. As a result, it dominated the computer world until the rise of minicomputers.
It ran a variety of software, such as the MVS operating system.
The System/360 was supplanted by the IBM System/370.
Contents
History
Before the IBM 360, in 1959-1964, IBM provided four major product lines of computers. They had small business computers like the 1401, large business computers like the 7070, small scientific computers like the 1620, and large scientific machines like the 709x series. All were incompatible, and so 4 complete sets of operating systems and development tools were being supported simultaneously. This was becoming a problem as manufacturers were providing more and more complex software. So, they came up with the idea of ONE compatible computer product line that would satisfy both business and scientific computing users. The name System 360 came from supporting the full circle of computing needs.
IBM literally bet the company on the success of the 360. If it had been a flop, they very well could have gone out of business. But, it was a VERY well thought-out bet, and of course, history shows that it was one of the most successful products of all time. They DID have some serious trouble getting machines into user's hands, however.
First, they had decided to make everything possible themselves. Previous IBM computers used commercial components (resistors, diodes, transistors) but for the 360, IBM was going to make their own transistors and diodes, and fabricate the circuit modules themselves. In 1965 they made one million SLT modules, the next year it was about six million, and in 1967 through 1969 they made between 11 and 12 million SLT modules per year! Ramping production up to this level was a major project.
The second issue was software, most specifically operating system software. There were two lower-level systems for the smallest machines, Disk OS and Tape OS. For machines of the 360/50 class, there was OS/360 MFT, which had memory partitions that were set by the operators. And, then, there was the top of the line system, OS/360 MVT, which could dynamically alter the main memory partitions based on the mix of jobs to be run.
The MVT system was so complicated that IBM was VERY late in delivering it. It led to some books such as Fred Brooks' "The Mythical Man-Month" which described some of the issues in scaling up very large software projects.
Specifications
- The 360 is a 32-bit machine;
- 16 general purpose 32-bit registers, 0 to 15 (usually Equated to the labels "R0" through "R15")
- 4 floating point 64-bit registers numbered 0, 2, 4 and 6; and
- a Program Status Word (PSW); it contains the privileged bit, the program counter, and the memory protection key.
The 360 is a big-endian machine, with values stored as high to low.
Other than the model /20, all 360's used I/O processors called channels, to which all peripherals were attached via IBM I/O channels. On lower machines (/30 through the /50) the channels were emulated in microcode. On higher machines (/65 and up) the channels were separate boxes directly connected to the main memory.
The 360 instruction set had 3 major classes of instructions, register to register, specified in a 16-bit field; register to indexed storage, specified in 32 bits; and storage to storage, specified in 48 bits. There was a 2-bit instruction length field in the op-code to specify the length of the instruction. The op-code always occupied 8 bits.
The register to indexed storage instruction had a 4-bit field to specify the base register, a 4-bit field for the index register and a 12-bit field for the offset. The contents of the base register, the index register and the offset were added to produce the physical address of the operand. If the base register was zero, then it was not added to the effective address.
The storage to storage instructions specified two storage locations, and were used for instructions that moved byte strings, compared byte strings and translated byte strings to different character encodings.
Memory management
In the initial models, memory management was provided with protection keys. Each 2K-byte block of memory had a 4-bit register which held a key value; the PSW contained the key of the currently running code, and writes to a given block were only allowed when they matched.
A feature of the 360 instruction set was that all object program files were relocatable, due to the use of the base register. The OS could load a program at any place in main memory, and then set the base register to the beginning of that memory partition. But, a limitation of that was that once a program started running, it began to use physical addresses for data, and the return address from a subroutine call. Therefore, once started, the program could not be relocated to a different memory area.
IBM did not adequately think out all the implications of the interaction of this with swapping, and with lots of programs coming and going in random-sized memory blocks, memory fragmentation could build up, turning memory into a checkerboard of unused space, with lots of little unused gaps between blocks that were in use. There were tricks to avoid this, like requiring all jobs to occupy regions with integral relationships (like 50 K, 100 K, 150 K, 200 K, etc).
One of the designer, Gerald Blaauw, had initiallly proposed adding a mechanism, later nicknamed the 'Blaauw Box', which apparently added a special (invisible to the program) base register that would be added to all memory references, so that the program could be fooled into seeing itself as always running at location zero. Thus, the program could be moved around in memory as needed, after being swapped out and back in.
That was originally proposed as standard mechanism for the 360's, but the decision was made not to add it. IBM then proposed it as a special 'add-on' for organizations which wanted time-sharing on 360's, but the clients turned it down because they wanted virtual memory, not just relocation.
Virtual memory was finally added to one model in the line, the Model 67.
Models
The 360 series spanned a wide range of performance, with 6 major models, plus a few special machines.
| Model | Announced | Shipped | Withdrawn |
|---|---|---|---|
| 20 | 18 November, 1964 | April, 1966 | N/A |
| 22 | 7 April, 1971 | June, 1971 | 7 October, 1977 |
| 25 | 3 January, 1968 | October, 1968 | 7 October, 1977 |
| 30 | 7 April, 1964 | June, 1965 | 22 June, 1970 |
| 40 | 7 April, 1964 | April, 1965 | 7 October, 1977 |
| 44 | 16 August, 1965 | June, 1966 | 24 September, 1973 |
| 50 | 7 April, 1964 | August, 1965 | 15 March, 1977 |
| 60 | 7 April, 1964 | 1 | 22 April, 1965 |
| 62 | 7 April, 1964 | 1 | 22 April, 1965 |
| 65 | 22 April, 1965 | November, 1965 | 15 March, 1977 |
| 67 | 16 August, 1965 | May, 1966 | 15 March, 1977 |
| 70 | 7 April, 1964 | 2 | 22 April, 1965 |
| 75 | 22 April, 1965 | January, 1966 | 15 March, 1977 |
| 85 | 30 January, 1968 | December, 1969 | 24 June, 1971 |
| 91 | 18 January, 1966 | October, 1967 | 20 February, 1967 |
| 92 | 17 August, 1964 | 3 | N/A |
| 95 | 4 | February, 1968 | N/A |
| 195 | 20 August, 1969 | March, 1971 | 9 February, 1977 |
- Replaced by Model 65
- Replaced by Model 75
- Became Model 91
- US Government only
The 360/20 was a "half-size" 360, it only implemented 16-bit size operations, and had only 8 general purpose registers, so that is not included as a real member of the 360 series.
Most 360's used microcode, but the 360/44 did not, and also 360/91 and /95 and /195 (which were superscalar machines and were not micro-coded).
The 360/30 internally had 8-bit wide memory and 8-bit data paths, but emulated the full 32-bit instruction set. It was rated at 30K to 40K instructions/second, depending on instruction mix. The processor was so slow that when I/O was operating, the CPU was totally dedicated to handling the channel operation. The 360/30 had the local storage (register set) in a separately addressed section of main memory.
The 360/40 internally had 16-bit memory and data paths, and was rated at about 80K instructions/second.
The 360/50 was a full 32-bit implementation, and rated at about 160K IPS.
The 360/40 and 360/50 also used a separate core storage for the registers.
The 360/65 had 64-bit memory, and a 56-bit ALU, so it could process double-precision floating point in one cycle. It allowed pairs of identical memory units to be interleaved, increasing performance even more. Memory cycle time was 640 ns, pretty fast for its time.
It was possible to connect two /65s to one memory system to create a multi-processor system, although it was not twice as fast as a single CPU, due to memory interference. It did save some cost as you did not have to duplicate memory and peripherals. A special version of the OS/MVT system called MP65 was developed for the dual processor system, but a lot of installations used it on a single processor because it had enhanced error recovery. The /65 was rated over 600 K IPS.
A variant of the 360/65 was the 360/67, which added segmention and virtual memory, as well as optional extended virtual addressing (normally 24 bits, the option extended them to 32 bits). A segment (specified by the high bits of the virtual address) could be up to 1Mbyte; they contained up to 256 4Kbyte pages. This mechanism, named "Dynamic Address Translation", was the basis of the DAT later added to all the models of the follow-on System/370.
The Model 67 too was available as a two-CPU system. It was also capable of virtualization (the first machine to do so, apparently), and the CP operating system (the ancestor of IBM's VM operating system) was developed for it to take advantage of this.
The 360/75 was the top end of the classic 360 machines.
All of these models were built with SLT (Solid Logic Technology) a hybrid technology where thin film resistors were deposited on 1/2" square ceramic substrates, then thick film silver conductors were deposited, and finally discrete transistor and diode die were flip-chip bonded to the traces.
This was pretty low-density technology, generally there were 2 2-input gates per SLT module, consisting of 4 diodes, 4-6 resistors and 2 transistors. IBM did not use flip-flops, but they made D-latches for registers. These occupied 2 1/2 SLT modules for one D-latch.
The 360/85 was a prototype for the 370/165, which was a very similar machine. It was the first IBM machine to use a cache memory ("storage buffer") in static RAM, as well as the first of their commercial machines to use monolithic integrated circuits (called MST for Monolithic Solid Technology).
The models 360/91 and 360/95 and the model 195 were very high end systems which could execute up to 8 instructions in parallel, using all the supercomputing techniques available.
Emulation
I don't think there is any direct S/360 emulator out there... However I'm pretty sure that Hercules will run System 360 software, as the 370 is upwards compatible with the 360.
Further reading
- Emerson W. Pugh, Lyle R. Johnson, John H. Palmer, "IBM's 360 and Early 370 Systems", MIT Press, 1991
- G. M. Amdahl, G. A. Blaauw, F. P. Brooks, Jr., Architecture of the IBM System/360, IBM Journal, April 1964
- G. A. Blaauw, F. P. Brooks, Jr., The Structure of SYSTEM/360: Part I - Outline of the logical structure, IBM Systems Journal, Vol. 3, No. 2, 1964
- David Gifford, Alfred Spector, Richard Case, Andris Padegs, Case Study: IBM's System/360-370 Architecture, Communications of the ACM, Vol. 30, No. 4, April 1987
- Andris Padegs, System/360 and Beyond. IBM Journal of Research and Development, Vol. 25, No. 5, September 1981
