HLH Orion

The Orion was a series of 32-bit super-minicomputers designed and produced in the 1980s by High Level Hardware Limited (HLH), a company based in Oxford, UK. The company produced four versions of the machine:

The original Orion, sometimes referred to as the "Microcodeable Orion".
The Orion 1/05, in which the microcodeable CPU was replaced with the much faster Fairchild Clipper RISC C-100 processor providing approximately 5.5 MIPS of integer performance and 1 Mflop of double precision floating point performance.
The Orion 1/07 which offered approximately 33% greater performance over the 1/05 (7.3 MIPS and 1.33 Mflops).
The Orion 1/10 based on a later generation C-300 Clipper from the Advanced Processor Division at Intergraph Corporation that required extensive cooling. The Orion 1/10 offered a further 30% improvement for integer and single precision floating point operations and over 150% improvement for double precision floating point (10 MIPS and 3 Mflops).

All four machines employed the same I/O sub-system.

Background

High Level Hardware was an independent British company formed in early 1982 by David G. Small and Timothy B. Robinson. David Small was previously a founder shareholder and director of Oxford-based Research Machines Limited. Both partners were previously senior members of Research Machine's Special Projects Group. In 1984, as a result of that research, High Level Hardware launched the Orion, a high performance, microcodeable, UNIX superminicomputer targeted particularly at scientific applications such as mathematical modeling, artificial intelligence and symbolic algebra.

In April 1987 High Level Hardware introduced a series of Orions based upon the Fairchild Clipper processor but abandoned the hardware market in late 1989 to concentrate on high-end Apple Macintosh sales.

Microcodeable Orion

The original Orion employed a processor architecture based on Am2900-series devices. This CPU was novel in that its microcode was writable; in other words, its instruction set could be redefined. This facility was used to customise some Orions with instruction sets optimised to run the Occam and LISP programming languages^[1] or even to compute fractals.^[2]

The central processing unit

The CPU consisted of an ALU that was built around the Am2901 bit-sliced microprocessor. To this a byte manipulation unit was added which could perform the shifting, rotating and masking operation required for handling eight and sixteen bit data. Additional logic was provided to support both signed and unsigned two's complement comparisons in a single operation, multiple precision arithmetic and floating point normalization. Most operations could be performed in 150 ns, however the cycle time was variable from 125 ns to 200 ns under microprogram control so that timing could be optimized. A microsequencer, based around the Am2910, directed the control flow though the microprogram. It could perform branches, loops and subroutine calls most of which could be conditional on any of several CPU status conditions.

The CPU instruction decoder, decoded machine level instructions (as opposed to micro-instructions). This was achieved by using map tables held in fast parity checked RAM which mapped one byte opcodes onto micro-instruction addresses. Control was transferred to these addresses using a special sequencer operation which was performed in parallel with other CPU functions. Hence instruction decoding overlapped instruction execution.

An escape mechanism was provided to allow the instruction set to be expanded beyond the 256 entries selected by any one opcode. A further mechanism existed to switch between several sets of dispatch tables, allowing the machine to support multiple instruction sets concurrently. Using this mechanism a different instruction set could be selected each time a context switch occurred. This mechanism was also used to implement privileged instruction, dynamic profiling (for performance monitoring) and multiple CPU modes (e. g. User and Kernel).

The role of the cache memory, independent of the main memory, was to hold the top of an evaluation stack for a procedure oriented language. The cache had a two cycle latency after which it could deliver one word per cycle and was divided into a number of pages each with 512 32-bit words with parity protection. The pages were grouped in pairs with an architectural maximum of 16 pairs. The original machine implemented two pairs. The second member of each pair was typically used as additional fast registers and scratch storage without affecting the stack page. The lower nine bits of the CPU register, which addressed the cache, was implemented with counters and allowed increment and decrement operations (push and pop) as wells as random access.

The control store

The control store was built using high speed static RAMs. This was normally loaded at bootstrap time, allowing the machine to be fully user microprogrammable. The control store cycle time was 125 ns, equal to the fastest CPU cycle. The architecture allowed for up to 32 Kwords (64 bit word length) of control store however due to the limitation in memory technology the original implementation allowed a maximum of 8 Kwords. The standard configuration had 4 Kwords on a single circuit board. Two such boards could be installed. Parity checking was provided. To achieve the required speed at reasonable cost, a two-level pipeline was employed around the control store. Later a 16 Kword board was implemented giving a maximum control store size of 32 Kwords.

Main memory

Main memory was organised as 32-bit words with two-way interleaving, allowing 64 bits of data to be fetched or stored in one operation. In normal operation main memory was accessed via a virtual memory management unit.

In the original implementation, each main memory module contained 0.5 Mbytes of storage with parity protection constructed using 64K dynamic MOS RAMs. Random access cycle time was 500 ns per 32-bit word but multi-word transfers, for example to and from the cache, yielded an effective cycle time of 250 ns per 32-bit word (16 Mbytes per second). The memory modules decoded 26-bit physical word addresses and within this limit total memory capacity was restricted only by the number of available system bus slots; depending on the I/O configuration of the system, up to 10 Mbytes of physical memory could be installed. A later implementation of the memory module increased the size to 2 MB using 256K RAMs.

Logical to physical address translation was carried out using a set of address translation tables. Each process has access to three independently extensible regions of memory, used typically for program, heap and stack. A fourth region was normally reserved for the operating system. The tables also contained a set of rights bits for each memory page giving full protection and supporting the implementation of demand paged virtual memory. The translation tables were cached in the CPU resulting, in most cases, in an overhead of only one microinstruction when performing address translation. The page size which was fixed by the hardware, was 4 Kbytes. Each logical region could be up to 256 Mbytes.

The input/output subsystem

The Orion I/O subsystems included a number of attached microcomputers to perform low level tasks such as running diagnostics and managing terminals and disks.

The diagnostic microcomputer (based around the Zilog Z80) was embedded within the CPU. Its functions included running a system confidence check when power is first applied, bootstrapping the CPU, and taking control should an unrecoverable control store parity error be detected. It could also be used to load new microcode dynamically whilst the machine was running. An RS-232C interface was provided to which a terminal could be attached. Extensive diagnostics could then be run in conjunction with special microcode to perform fault analysis in the event of a system failure. Problems could usually be isolated to one or two integrated circuits.

One or more intelligent I/O channels controlled peripheral activity. Each of these included a full function microcomputer based around the Z80 which performed control functions and housekeeping. Data transfers to and from peripheral devices took place via a direct memory access (DMA) path itself constructed using Am2901 bit-slice microprocessors. This allowed the full performance of the Orion memory system and of the peripheral device to be exploited, with the microcomputer able to take corrective action on soft I/O errors. Software on the Orion communicated with the microcomputer using a high level message passing protocol.

Operating system

The operating system for the microcodable Orion was OTS (Orion Time Sharing) version 1.x, a port of the 4.1BSD UNIX operating system.

The Clipper-powered Orions ran OTS version 2.x, a port of the 4.2BSD UNIX with some additions. This was not notably reliable or secure, and had a tendency to 'forget' process user IDs, randomly leaving user processes running as root.

HLH also produced a graphics terminal for the Orion called the StarPoint, to which they ported the X Window System.

HLH Orions at the University of Kent

The Orion series was moderately popular with the computer science departments of British universities, including Bath, Edinburgh, Heriot-Watt, Kent, Southampton, Warwick, York, King's College, London. A typical multi-user Orion configuration would have had 8 MB of RAM, an SMD hard disk (e.g. a 168 MB Kennedy or a 434 MB Fujitsu Eagle), a 60 MB QIC-24 tape drive and 8 to 32 RS-232 terminal ports.

Bibliography

Orion, A High Performance Personal Computer - Sales brochure produced by High Level Hardware Limited.
Orion 1/05 - Sales brochure produced by High Level Hardware Limited.
Orion Configuration Guide - Product information produced by High Level Hardware Limited.
Fiedler, S. "Hunting for High Performance with Orion." Unique, The UNIX System Information Source. 7.9 (1989): 11-12. Print.

References

External links

This article is issued from Wikipedia - version of the Saturday, March 19, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.