ICL 2900 Series
The ICL 2900 Series was a range of mainframe computer systems announced by the UK manufacturer ICL on 9 October 1974. The company had started development, under the name "New Range" immediately on its formation in 1968. The range was not designed to be compatible with any previous machines produced by the company, nor with any competitor's machines: rather, it was conceived as a synthetic option combining the best ideas available from a variety of sources.
In marketing terms, the 2900 Series was superseded by Series 39 in the mid-1980s; however, Series 39 was essentially a new set of machines implementing the 2900 Series architecture, as were subsequent ICL machines branded "Trimetra".
Origins
When ICL was formed in 1968 as a result of the merger ofInternational Computers and Tabulators with English Electric Leo Marconi and Elliott Automation, the company
considered a number of options for its future product line. These included enhancements to either ICT's 1900 Series or the English Electric System 4,
and a development based on J. K. Iliffe's Basic Language Machine. The option finally selected was the so-called Synthetic Option: a new design starting with a clean sheet of paper.
As the name implies, the design was influenced from many sources. These included ICL's own earlier machines. The design of Burroughs mainframes was influential, although ICL rejected the concept of optimising the design for one high-level language. The Multics system provided other ideas, notably in the area of protection. However, the biggest single outside influence was probably the MU5 machine developed at Manchester University.
Architectural concepts
The virtual machine
The 2900 Series architecture uses the concept of a "virtual machine" as the set of resources available to a program. The concept of a "virtual machine" in the 2900 Series architecture should not be confused with the way the term is used in other environments. Because each program runs in its own virtual machine, the concept may be likened to a process in other operating systems, while the 2900 Series process is more like a thread.The most obvious resource in a virtual machine is the virtual store. Other resources include peripherals, files, network connections, and so on.
Within a virtual machine, code can run at up to sixteen different layers of protection, called access levels. The most privileged levels of operating system code operate in the same virtual machine as the user application, as do intermediate levels such as the subsystems to implement filestore access and networking. System calls thus involve a change of protection level, but not an expensive call to invoke code in a different virtual machine. Every code module executes at a particular access level, and can invoke the functions offered by lower-level code, but cannot make direct access to memory or other resources at that level. The architecture thus offers a built-in encapsulation mechanism to ensure system integrity.
Segments of memory can be shared between virtual machines. There are two kinds of shared memory: public segments used by the operating system, and global segments used for application-level shared data: this latter mechanism is used only when there is an application requirement for two virtual machines to communicate. For example, global memory segments are used for database lock tables. Hardware semaphore instructions are available to synchronise access to such segments. A minor curiosity is that two virtual machines sharing a global segment will use different virtual addresses for the same memory locations, which means that virtual addresses cannot safely be passed from one VM to another.
Addressing mechanisms
The 2900 architecture supports a hardware-based call stack, providing an efficient vehicle for executing high-level language programs, especially those allowing recursive function calls. This was a forward-looking decision at the time, since it was expected that the dominant programming languages would initially be COBOL and FORTRAN. The architecture provides built-in mechanisms for making procedure calls using the stack, and special purpose registers for addressing the top of the stack and the base of the current stack frame.Off-stack data is typically addressed via a descriptor. This is a 64-bit structure containing a 32-bit virtual address, plus 32 bits of control information. The control information identifies whether the area being addressed is code or data; in the case of data, the size of the items addressed ; a flag to indicate whether hardware array-bound-checking is required; and various other refinements.
The 32-bit virtual address comprises a 14-bit segment number and an 18-bit displacement within the segment.
Technically the order code is not part of the 2900 architecture: this fact has been exploited to emulate other machines by microcoding their instruction sets. In practice, however, all machines in the 2900 series implement a common order code or instruction set, known as the PLI. This is designed primarily as a target for high-level language compilers.
There are a number of registers, each designed for a special purpose. An accumulator register is available for general-purpose use, and may be 32, 64, or 128 bits in size. The B register is used for indexing into arrays; the LNB register points to the base of the current stack frame, with the SF register pointing to the movable 'top' of the stack; the DR register is used for holding descriptors for addressing into the heap, and so on. There are also two 32 bit pointers to off-stack data; XNB and LTB.
Data formats recognized by the PLI instructions include 32-bit unsigned integers; 32-bit and 64-bit twos-complement integers; 32-bit, 64-bit and 128-bit floating point; and 32-bit, 64-bit, and 128-bit packed decimal. Conventionally the boolean value true is represented as zero, false as minus one. Strings are held as arrays of 8-bit characters, conventionally encoded in EBCDIC. It is possible to use ISO instead of EBCDIC by setting a control bit in a privileged register; inter alia, this affects certain decimal conversion instructions.
Because some of the PLI instructions, notably those for procedure calling are very powerful, instruction rates on 2900 Series are not always directly comparable with those on competitors' hardware. ICL marketing literature tended to use the concept of "IBM equivalent MIPS", being the MIPS rating of an IBM mainframe that achieved the same throughput in application benchmarks. The efficiencies achieved by the 2900 architecture, notably the avoidance of system call overheads, compensated for relatively slow raw hardware performance.
Implementations
The first machines announced in the 2900 Series were the 2980 and 2970. The 2980 allowed one or two order code processors, each operating at up to 3 million instructions per second, with real memory configurable up to 8 megabytes, with a 500 nanosecond access time.The 2980 was initially the most powerful of ICL's New Range mainframe computers. In addition to the OCPs, it consisted of a store multiple access controller and one or more store access controllers, a general peripheral controller, one or more disc file controllers and a communications link controller, together with disc drives, tape decks, an operating station, line printers and card readers. It supported the VME/B, VME/K and Edinburgh Multiple Access System operating systems. A typical 2980 configuration would cost about £2 million.
Unlike the 2980, the 2970 and the subsequent 2960 were microcoded, and thus allowed emulation of instruction sets such as that of the older 1900 Series or the System 4.
A 2900 Series machine was constructed from a number of functional modules, each contained in a separate cabinet. Peripheral devices were connected using ICL's Primitive Interface to a Port Adapter on the SMAC. Logical addressing was employed and used a group scheme to identify system components in terms of Ports, Trunks and Streams.
A Trunk was a generic name and a hardware address within a Port to which a peripheral controller would be assigned. A Trunk was a generic name for a controller for a number of Stream devices.A Stream was the generic name for the channel under which individual peripheral devices could be referenced.
The boot process for the 2960 Series is worthy of a special mention: the OCP contained a mini OPER terminal and a cassette deck. At boot, the OCP would perform its Initial Program Load from the nominated IPL device. The IPL code provided the means for the OCP to discover the system's hardware configuration, by enquiring down the Stream, Trunk and Port to find the default or manually elected boot device for the microcode set and/or Operating System to be booted. This process was called a GROPE or General Reconnaissance Of Peripheral Equipment. The cassette load method also allowed engineering staff to load and execute diagnostic software.