HeliOS


Helios is a discontinued Unix-like operating system for parallel computers. It was developed and published by Perihelion Software. Its primary architecture is the Transputer. Helios' microkernel implements a distributed namespace and messaging protocol, through which services are accessed. A POSIX compatibility library enables the use of Unix application software, and the system provides most of the usual Unix utilities.
Work on Helios began in the autumn of 1986. 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.

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.
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. Later Tim King and Nick Garnett gave permission to release the sources under the GNU Public License v3.

Kernel and nucleus

Helios was designed for a network of multiple nodes, connected by multiple high-bandwidth communications links. Nodes can 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, the null server, and the logger server.

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. 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 extends 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 programs written in the occam programming language.

Hardware

Helios was predominantly intended to be used with Transputer systems. It is compatible with 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 can run on T4xx and T8xx, 32-bit Transputers and includes 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 used by the Active Book tablet device.