The Taos Operating System (1991)

{This material originally appeared in the March, 1991 International Edition of Byte magazine, a McGraw-Hill publication} 

To describe TAOS (pronounced 'dowse' as in the oriental religion Daoism) as an

innovatory operating system would be a profound understatement. It has so few

points of similarity with operating systems like MS-DOS that many observers,

myself included, have initially had trouble believing in it at all. For one

thing TAOS is strongly Object Oriented and makes almost no distinction between

data files and executable programs. It brings together many advanced ideas

about Persistent Objects, Object Oriented Virtual Memory and Dataflow

programming into one wholly novel system. It is a parallel operating system

which configures itself automatically to run on a network of distributed

processors and load-balances itself. More incredibly still, it promises to run

exactly the same code on different processors in a heterogeneous network (eg.

a mixture of Inmos Transputers, Intel 80386 and Acorn ARMs); it offers CPU


Before proceeding I must stress that TAOS is not finished yet and there are no

commercial ports of it in use. Some of the radical features mentioned above

are only partially implemented at the time of writing. This article is

therefore more of a preview of the concepts in TAOS than a full 'review'.

TAOS is being developed by Tao Systems UK Ltd., a small firm that has existed

for about 9 months, and whose leading spokesmen are Nick Spicer and Chris

Hinsley, two experienced programmers from very different backgrounds. Spicer

was a founder member of the European arm of Microway, the US firm which

specialises in high-performance floating point hardware and more latterly in

Transputer products. Spicer was Technical Manager and systems programmer.

Hinsley on the other hand is a veteran games programmer, an assembler wizard

who has been responsible for successful Atari ST and Amiga games like

'Verminator' and 'Onslaught'. Though writing exclusively in assembler, Hinsley

developed an Object Oriented style for writing games based on extensive macro

libraries, and this provided the original inspiration for TAOS. Spicer added

the parallel aspects to TAOS, based on his experience with Transputers and his

dissatisfaction with Occam. 


Perhaps the most important thing to understand about TAOS, before even

discussing the way it works, is that it is designed to execute a virtual

machine language called VP (for Virtual Processor). VP is the binary code of

an imaginary RISC-like processor with about 32 instructions, designed by Tao

Systems. In order to execute VP on a real processor, a translator will be

provided from VP into the native machine code of the target processor.

The ingenious part is that the translation takes place at program load time,

not during runtime as some erroneous reports have stated. This is NOT an

interpreted pseudo-code as used in the UCSD P-System or POP-11. When a program

module is loaded onto a Transputer node it will get turned into Transputer

code before it is run, whereas if it gets loaded onto an 80386 it will be

turned into Intel code. 

Tao Systems is currently committed to produce translators for the Inmos T800

transputer, Motorola 680x0, PgC7600 (see article in this issue), Intel

80386/80486, Acorn ARM and Sun SPARC. Of these the first three have been

written. The TAOS program loader, called ALEX, is part of the kernel that runs

on each node in a parallel computer, and as ALEX loads each program module it

performs the native code translation and optimization. Because TAOS is

extremely modular in nature and employs a novel late binding scheme, the size

of each module to be translated will be very small, and since all the target

processors are powerful CPUs the time taken up in translation should be quite

small. ALEX is not yet completed and the prototype TAOS systems which have

been demonstrated employ a conventional VP assembler to produce executable

native code. Tao Systems seems confident that the design of the VP instruction

set is such that writing the individual translators should not be too

difficult, even to such un-RISC like processors as the 80486.

So the first point about TAOS is that everything in it (apart from the native

code kernels at each node) consists of VP code, including all the applications.

A parallel TAOS program consists of a number of tool modules which you can run

on any mixture of the supported target processors without even knowing what

they are. If TAOS becomes established as an operating system then compilers

from C and other languages into VP will undoubtedly emerge.



Everything in TAOS is an object, and as in traditional OOPS, objects contain

both code and data. Under TAOS the code part is called a 'tool', equivalent to

a 'method' in conventional OOPs. Even what would be considered data files

under a conventional OS are objects which have tools that can for example

display their name, and check the access rights of a user.

All the executable code in TAOS is contained in tools. Tools must be fully re-

entrant, relocatable and side-effect free and cannot therefore contain static

data; so TAOS groups data and code together into objects, but rigorously

segregates code from data within an object. Tools are the smallest units of

executable code under TAOS so you can think of them as being like subroutines,

or C functions, or Pascal procedures. However tools are independently

executable so a better analogy would be with Forth, where words can always be

executed directly without having to call them from a main program.

Some tools are called 'permanent tools' and get loaded up by the boot system;

these form the heart of the operating system itself. Some tools are 'semi-

permanent' and these are loaded at boot time by a user-created configuration

process, but once loaded they and become part of the operating system and

cannot be de-activated. These tools are roughly equivalent to the device

drivers and extensions loaded by CONFIG.SYS and AUTOEXEC.BAT under PC-DOS.

Finally there are 'application tools' which are the user executable programs

of TAOS. Application tools can be 'virtual' or 'non-virtual'. Non-virtual

tools are loaded with the application and remain in memory until it is de-

activated (ie. quits). Virtual tools only get loaded into memory when the

application calls them, and when they cease to execute they can be marked as

'freeable' and the space they occupy can be reclaimed for use by another tool.

Virtual tools are quite similar in concept to Borland's VROOM system or to

OS/2's Dynamic Link Libraries. Virtual and non-Virtual tools are collectively

referred to as 'external' tools and they have names that resemble PC-DOS or

Unix pathnames by which they are accessed. They are normally cached so that a

subsequent access does not need to reload them from disk, unless memory is in

very short supply. An application in TAOS thus consists largely of named

references to external tools, allowing a great degree of reuse of code, and

keeping the individual executable units very small.

As well as external tools TAOS has 'library' tools and 'local' tools.

Library tools are kept in named libraries and can be shared by many

applications; like external methods they are cached for future use. Local

tools are part of the actual code of an application and have single unique

names, not pathnames. A local tool always overrides any external tool with the

same name. 

All TAOS programs are started up by a 'control object'. A control object is

primarily a data object, a sort of template, which contains all the

information necessary to load and run the tools which make up the program, but

it also has code which sets the loading of tools in motion. A control object

roughly corresponds to a task or process in other operating systems. It will

contain a list of the pathnames of all its component tools, the stack space

each one requires and a bit-mask which define what kind of messages it will

accept. Control objects are executed by the permanent TAOS kernel which

resides on each node of a parallel system, which then loads and runs the

necessary tools. Control objects can spawn children, and it is by this means

that TAOS programs distribute themselves around a parallel processor network.

Control objects can be inactivated without being removed from memory, and may

then be woken by other control objects sending them mail messages.

One way of looking at the TAOS tool system is that all programs employ very

late, ie. loadtime or runtime, binding. Programs assembled or compiled under

TAOS will not need to be linked for linkage occurs when a program is run,

under the control of its control object. You can recompile a single tool

without recompiling the whole application, and even design applications that

load different tools according to the runtime environment they encounter.


TAOS is a message passing operating system which uses 'mailboxes' for

communication between processes. All program I/O takes place through the mail

system, as does the distribution of executable code. Every control object is

automatically given a mailbox by TAOS, and can send or receive mail from any

other object whose mailing address it knows. These will always include its own

parents and children and any named resources like disk drives and VDU displays,

and may also include its siblings if measures are taken to record their

addresses when they are created. The kernel on each TAOS node has a permanent

Mail Guardian tool which handles all incoming mail for local objects on that

node, all outgoing mail, and mail which is to be forwarded to another node. 

The format of a TAOS mail messages includes a header that contains the size and

type of a message. There are 16 predefined message types including system,

executable code, error data, and debugging data and the programmer can use

numbered types up to 255 to make private communications between two objects.

The type mask allows the Message Guardian to trap system messages such as

executable code destined for the kernel, and it also allows user objects to

prioritize the way they read their waiting mail by type.

The header also contains the addresses of the originator and destination of the

message, of any other intended recipients for forwarding, and where a reply (if

one is requested) is to be sent. Mail can be sent to an inactivated object,

and may re-activate it as a child of the sender object so it can read the

message and respond immediately. In other circumstances such a message may

just sit in the inactive object's mailbox until some other event wakens it. If

such an inactive object gets removed due to a shortage of free memory, any

pending mail is stored in the object's filefolder (ie. is written to disk) and

re-sent next time the object is loaded. This might also happen when the TAOS

system is closed down, so that messages as well as objects can be persistent.

TAOS dynamically allocates the buffers that receive mail messages. In the

event that there is not enough memory to create the buffer, the Guardian reads

the header, discards the message data and replies to the sender that the

message has been trashed. The sender can then retry using a different route. 



TAOS stores objects onto mass storage media like hard disks via the mailbox

system, in objects called 'filefolders'. A filefolder has some similarities to

a DOS or Unix directory, but rather than being a passive storage structure it

is an active object (in fact a control object). The tools attached to every

filefolder are responsible for storing and retrieving objects from the folder

and for negotiating with the hardware device drivers that are necessary for

this transfer. Because filefolders are actually instances of a broader category

of TAOS object called 'filters' they may also process the data they transfer,

for example compressing and expanding it transparently to the user.

I mentioned above that TAOS tools have pathnames like those used to identify

files in a hierarchical directory system such as DOS. Because TAOS cannot

permit the duplication of files that DOS allows, pathnames are actually

handled rather differently. Where DOS relies on the PATH command and the

user's own knowledge of the directory tree and its contents, TAOS must

always be able automatically to locate objects. The pathname of a TAOS object

IS the object name, rather than just a qualifying prefix indicating its

current location. Therefore TAOS has built-in defaults related to the object

type; tools are expected by default to be in the 'tools' filefolder. So if you

request 'mystuff' TAOS will look for 'tools/mystuff' unless you explicitly

specify another filefolder. The path 'tools/mystuff' is actually a message to

the control object 'tools' requesting it to retrieve an object called


In large or multi-user systems there may be multiple server devices, and so

multiple 'tools' folders. In this case TAOS adds the the mailbox ID of a

'master server' to the path, roughly equivalent to a DOS drive; for example

'/dicks_server:/tools/mystuff'. All future objects will be retrieved from this

server until you explicitly change it.

Filters in general are control objects that receive input from a mailbox, and a

parameter string, and send output to another mailbox. The destination address

for the output is contained in the input message as explained above. The

parameter string  (which may be null) may tell the filter which of several

actions to perform on its input. Filefolders are just one type of filter. In

fact all TAOS applications constructed from TaoScript commands (see later) are

just pipelines of filters running in parallel and passing data from one to the

other. TAOS is a dataflow operating system, extending the Unix pipe concept to

its logical conclusion.


Tao Systems is seeking a patent on the algorithm used to distribute parallel

programs over a network of processors, and so I am not allowed to describe it

in detail. It's basically a smarter enhancement of the flood-fill type of

algorithm, which can take into account the loading of each processor node as

measured by the number of processes running on it. An application like the

Mandelbrot which requires a large number of identical processes will get

distributed in a manner which resembles water running down a mountain, where

the flow seeks out the 'gullies' or lowest points. Tao System claims that this

mechanism achieves a high degree of automatic load balancing.

Very crudely, each node knows the current loading of all its nearest neighbors

and any control object can spawn children onto the neighbour that is least

busy, using a kernel call which invokes the mail system to transfer the

executable VP code. Deadlock due to circular network paths is avoided by an

incrementally created a routing table that remembers which paths have already

been traversed. This is the part of the algorithm which is the subject of the

patent, and it ought to work for any network topology at all. The routing

table allows messages to find their destination mailboxes. The routing

algorithm may, hardware permitting, generate multiple paths between two nodes

which can be used as alternatives when mail gets blocked due to a shortage of

buffer memory or a hardware failure.

When necessary you can eschew the automatic mechanism and specify the

particular node that an object is to run on. You can also invoke a partially

automatic mechanism in which you explicitly send a number of objects to a node

but let TAOS distribute them from there. For example you could specify that a

1000 process Mandelbrot calculation should be run by sending 10 groups of 100

objects to different nodes of the network but letting TAOS complete the

distribution. The TAOS kernel contains a time-slice scheduler that allows many

objects to run on the same processor. Box 1 lists the TAOS Kernel Calls

(similar to DOS BIOS interrupts), and if you look at the entries under Control

Object Management whose names begin with OPEN you will get some idea of how

distribution is achieved.

From a programmer's point of view remote interprocess communication is

transparent under TAOS. You only need to know the mailbox address of a remote

object, and then TAOS will route messages to it without you specifying the

route. Tao Systems claims that near optimal routings are usually achieved.


You interact with TAOS via a job control language edit/interpreter called

TaoScribe which processes a language called TaoScript. This is a dataflow

language which describes the flow of data through pipelines of tools specified

by their paths. For example :-

/data2 < proc2 < proc1 < /data1

would pass the data object 'data1' through the two tools 'proc1' and 'proc2'

and then store the output into data object 'data2'. Tools 1 and 2 will be 

executed concurrently, possibly on different processors, and both will be

started up before any data is transferred.

/hd/data2 /hd/data3 > proc3

would send both data streams into the same tool, while :-

/dtp_stuff/chapter2 "parameter" > tformat

sends the parameter string as well as the data into a 'tformat' tool. The only

operators in TaoScript are /,< and > but these can be used in combination to

create forks and joins as well as linear pipes. The resulting programs are in

my opinion difficult to read though. There are no control constructs such as

IF..THEN or DO..WHILE in TaoScript because all such control flow is governed

inside the tools themselves, by interpreting parameter strings. So :-

/data2 "TRUE, FALSE" > proc3

might tell proc3 to send its output to one of the objects TRUE or FALSE

according to the value of /data2. Groups of TaoScript commands can be saved

as named objects and used as single commands, just like DOS batch files. The

ordering of commands within a TaoScript program is very often irrelevant since

the tools are all running in parallel and the dataflow governs the order of

their execution.


There is also a simple Graphical User Interface built-into TAOS. Any control

object can create a window object, which uses a buffer local to the object for

maximum speed. These windows are sensitive to mouse events such as button

clicks and dragging. Control objects do not need to worry about window

movement or overlapping and refreshing which are handled transparently by the

GUI supervisor, but they can receive mouse X,Y and time data from button


Only one window, the Input Window, can receive user input at any one time and

this window is indicated visually by a change of border color and by

automatically being brought to the top of the pile. An object can send

messages to its window to define 2D screen areas as Area Event triggers; the

GUI monitors such areas and sends an Area Event back to the object if the

mouse pointer enters the area. Areas can range from one pixel to the whole

window. The GUI can also monitor areas by sending a continuous stream of X,Y

data whenever the pointer is in the area. These simple facilities allow you to

implement pop-up menus and dialog boxes.

The GUI supports 8-bit color palettes, of which the first 8 colors are defined

as EGA compatible defaults.


I have seen prototype versions of TAOS running on 5 or 6 Inmos Transputers in

a PC host. The GUI is lightning fast and the demonstrations of multiple

windowed Mandelbrot plots are very impressive indeed. However I have had no

direct experience of programming under it, nor do I have complete

documentation. Certain parts of TAOS, including the ALEX language translators,

were not complete when this article went to press and some aspects of the

design are still undergoing evolution. Tao Systems claims for the efficiency

of parallel program distribution and message routing are very strong and

will need to be independently tested by some parallel computer vendors.

There is no doubt though that TAOS brings together many clever ideas in an

elegant way. The philosophy it embodies is right on target for the next

generation of operating systems, with its emphasis on persistent objects,

dataflow and re-usable modular tools. The VP system for supporting multiple

processor types is so ingenious that you wonder other operating system vendors

have not tried it, until you reflect that it is only really viable for a

starting-from-scratch OS; the effort of re-writing all PC, or Mac or Unix

software in VP would clearly be prohibitive.

Tao Systems is now busy demonstrating TAOS to a number of big names in parallel

processing, including some from Japan, and I shall be following the progress of

TAOS with great interest.

Dick Pountain, Nov 1990


BOX 1.


The TAOS Kernel Calls listed in functional groups:-

Memory Management

ALLOCFAST       allocate memory block from fast memory pool

ALLOCMIN        allocate memory block given minimum size required

ALLOCMAX        allocate memory block given maximum size required

FREEMEM         free memory block

Object Memory Management

COPYNODE        copy object

COPYHEAD        copy object to head of linked list

COPYTAIL        copy object to tail of linked list

DUMPLIST        free memory of all nodes on a list

FREELIST        UNALEX and free memory of all nodes on a list

Mailbox Management

SENDMAIL        Send mail message

COPYMAIL        Copy mail message then send copy

READMAIL        Read mailbox

Control Object Management

STARTCONTROL    Start a control object locally

OPENCONTROL     Copy a control object and start locally

OPENCHILD       Distribute and start a control object in network

CLOSECONTROL    Close a local control object

OPENARRAY       Distribute and open a number of control objects

                 in the network

OPENFARM        Distribute and open multiple copies of a control

                 object in the network

OPENDEVICE      Transport a control object to a specified network

                 node and start

OPENREMOTE      Transport a control object to a specified network

                 node for distribution from that node, then start

Tool Object Management

VCALL           Virtual Call tool object

FINDTOOL        Enquire if tool is available locally

OPENTOOL        Request tool load

FLUSHPETL       Flush un-referenced tools from Permanent and

                 External Tool List

General Object Management

VADDR           Obtain address of an embedded object

OBJPROC         Process an object in same thread

LISTPROC        Process a linked list of objects in same thread

LISTTEST        List enquiry for types of objects

LISTINFO        Enquire general list information

Global Variable Management

DECLARE         Declare named 64 bit integer value to child control


ENQUIRE         Obtain 64 bit value for declared variable name from

                 family tree

UNDECLARE       Locally remove last instance of a named variable

                 declaration from declaration stack

Processor Type Node Identification

FINDTYPE        Enquire processor ID of processor node conforming

                 to specified processor type and minimum memory


Local Timer Functions

GETTIME         Obtain local processor timer count

DELAY           Timed deschedule

Template Object Management

ALEX            Convert template to Process Ready

UNALEX          Invalidate Process Ready status of object