HeliOS
Lua error in package.lua at line 80: module 'strict' not found.
| Developer | Perihelion Software |
|---|---|
| Written in | {{#property:p277}} |
| OS family | Unix-like |
| Working state | Historic |
| Source model | Closed source |
| Initial release | 1988 |
| Latest release | 1.3.1 / (date unknown) |
| Kernel type | Microkernel |
| Official website | {{ |
Helios was a Unix-like operating system for parallel computers developed and sold by Perihelion Software. It was most commonly used on various Transputer systems, but also supported other architectures. The system provided a micro-kernel that implemented a distributed name space and messaging protocol, through which services were accessed. A POSIX compatibility library enabled the use of Unix application software, and the system provided most of the usual Unix utilities.
Work on Helios began in the autumn of 1986.[1] Its success was limited by the commercial failure of the Transputer, and efforts to move to other architectures met with limited success. Perihelion ceased trading in 1998.[2]
Contents
Development
In the early 1980s, Tim King joined MetaComCo from the University of Bath, bringing with him some rights to an operating system called TRIPOS.[3] MetaComCo secured a contract from Commodore to work on AmigaOS, with the AmigaDOS component being derived from TRIPOS. In 1986, King left MetaComCo to found Perihelion Software, and began development of a parallel operating system, initially targeted at the INMOS Transputer series of processors. Helios extended TRIPOS' use of a light-weight message passing architecture to networked parallel machines.
Helios 1.0 was the first commercial release in the summer of 1988, followed by version 1.1 in autumn 1989, 1.1a in early 1990, 1.2 in December 1990 followed by 1.2.1 and 1.2.2 updates. Version 1.3 was a significant upgrade with numerous utility, library, server and driver improvements. The last commercial release was 1.3.1.
Kernel and nucleus
Helios was designed for a network of multiple nodes, connected by multiple high-bandwidth communications links. Nodes could be dedicated processing nodes, or processors with attached I/O devices. Small systems might consist of a host PC or workstation connected to a set of several processing nodes, while larger systems might have hundreds of processing nodes supported by dedicated nodes for storage, graphics, or user terminals.
A Helios network requires at least one I/O Server node that is able to provide a file system server, console server and reset control for the processing nodes. At power on, the Helios nucleus is bootstrapped from the I/O server into the network. Each node is booted using a small first-stage loader that then downloads and initialises the nucleus proper. Once running, a node communicates with its neighbours, booting them in turn, if required.
The Helios nucleus is composed of the kernel, libraries, loader service and the processor manager service.
Kernel
The Helios kernel is effectively a micro-kernel, providing a minimal abstraction above the hardware with most services implemented as non-privileged server processes. It provides memory allocation, process management, message passing and synchronisation primitives.
Libraries
The Helios nucleus contains three libraries: the system, server and utility libraries. The utility library provides some basic library routines for C programming that are shared by the other libraries. The system library provides the basic kernel interface, converting C function calls into messages sent to and from the kernel. It implements an abstraction that allows communication between processes regardless of their location in the network. The server library provides name space support functions for writing Helios servers, as described below.
Loader and processor manager
The remaining components of the nucleus are the loader and processor manager servers. Once the kernel is loaded, these processes are bootstrapped, and they integrate the newly running node into the Helios network.
Naming and servers
A key feature in Helios is its distributed name system. A Helios network implements a single unified name space, with a virtual root node, optional virtual network structuring nodes, nodes for each processor, and sub-processor name spaces provided by services. Names are similar to those in Unix, using a forward slash separating character and textual naming elements.
The name space is managed by the network server, which is started by the I/O server once the nucleus is booted on its first attached node. The network server uses a provided network map to allocate processor names and initialise drivers for hardware devices at specific nodes in the network. The kernel includes a name resolver, and manages a local cache of routes to previously resolved names.
Servers are Helios processes that implement the General Server Protocol, typically with the support of the server library. The server protocol is conceptually similar to the Unix VFS API, and more closely to Plan 9's 9P. It requires that servers represent their resources as files, with standardised open/read/write/close-style operations. Similar to facilities such as /proc in Plan 9 and other Unix-like operating systems, resources such as files, I/O devices, users, and processes are all represented as virtual files in the namespace served by their managing process.
Key servers in Helios are the previously mentioned loader, processor manager and network server, together with the session manager, the window server and the file server. Others include the keyboard, mouse, RS232 and Centronics servers (built into the host I/O server), the null server (like Unix's /dev/null), and the logger server (like Unix's syslog).
Programming and utilities
From a user's perspective, Helios is quite similar to Unix. Most of the usual utility programs are provided, some with extensions to reflect the availability of multiple machines.
What is not immediately apparent is that Helios extends the notion of Unix pipes into a language called Component Distribution Language (CDL). In CDL, a typical Unix shell pipeline such as ls | more is called a task force, and is transparently distributed by the Task Force Manager server across the available CPUs. CDL extended traditional Unix syntax with additional operators for bi-directional pipes, sequential and parallel process farm operators, load balancing and resource management.
Helios applications can be written using C, C++, FORTRAN and Modula-2. The POSIX library assists in porting existing Unix software, and provides a familiar environment for programmers. Helios does not support occam programs.
Hardware
Helios was predominantly an operating system for Transputer systems. It supported products from various manufacturers including INMOS' TRAM systems, the Meiko CS, Parsytec MultiCluster and SuperCluster, and the Telmat T.Node. The Atari Transputer Workstation was perhaps the highest profile Helios hardware, at least outside academia.
Helios ran on T4xx and T8xx, 32 bit Transputers (but not the T2xx 16 bit models) and offered device drivers for various SCSI, Ethernet and graphics hardware from Inmos, Transtech, and others.
In its later versions, Helios was ported to the TI TMS320C40 DSP, and the ARM architecture where it was used on the Active Book tablet device.
References
Further reading
- Lua error in package.lua at line 80: module 'strict' not found.
- Lua error in package.lua at line 80: module 'strict' not found.
