--- created_at: '2015-06-30T16:49:31.000Z' title: The Taos Operating System (1991) url: http://www.dickpountain.co.uk/home/computing/byte-articles/the-taos-operating-system-1991?hn author: vezzy-fnord points: 110 story_text: comment_text: num_comments: 93 story_id: story_title: story_url: parent_id: created_at_i: 1435682971 _tags: - story - author_vezzy-fnord - story_9806607 objectID: '9806607' year: 1991 --- [Source](http://www.dickpountain.co.uk/home/computing/byte-articles/the-taos-operating-system-1991?hn "Permalink to The Taos Operating System (1991) - dick pountain's pages") # The Taos Operating System (1991) - dick pountain's pages | ----- | | ## [dick pountain's pages][1] | Search this site | | * [Home][2] * [Blogs][3] * [Biography][4] * [Computing][5] * [Photo Gallery][6] * [Paintings][7] * [Cool Quotes][8] * [Materialism][9] * [Music][10] * [Sampling Reality][11] | | | ----- | | * [Home][2] * [Biography][4] * [Blogs][3] * [Computing][5] * [Byte Articles][12] * [Limits of Computing (1997)][13] * [Oberon/F (1994)][14] * [Parallel Course (July 1994)][15] * [The Oberon Language (1990)][16] * [The Oberon System (1992)][17] * The Taos Operating System (1991) * [PriPar Machines][18] * [Ruby Projects][19] * [Maths Libraries][20] * [Shoes projects][21] * [Creatures][22] * [Equation Solver][23] * [Factoriser][24] * [MatrixCalc][25] * [WordSieve][26] * [Scratch projects][27] * [Simpleware][28] * [Download page][29] * [Cool Quotes][8] * [Materialism][9] * [Sampling Reality][11] * [Music][10] * [A Sad Canticle][30] * [Algorhythmics][31] * [Béla Bartók][32] * [Just Plain Wrong][33] * [Just Plain Wrong][34] * [Spotify playlists][35] * [Paintings][7] * [Photo Gallery][6] * [Flickr Top 200][36] * [Sitemap][37] | [Home][2]‎ > ‎[Computing][5]‎ > ‎[Byte Articles][12]‎ > ‎ ### 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 transparency. 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.  **VP CODE** 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.                              **OBJECTS ** 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. **MAILBOXES ** 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.    **FILEFOLDERS** 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 'mystuff'. 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. **PARALLEL PROCESSING** 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. **TAOSCRIPT ** 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. **THE GUI ** 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 clicks. 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. **CONCLUSIONS ** 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                  objects 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                  requirement 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 | Comments | [Sign in][38]|[Report Abuse][39]|[Print Page][40]|Powered By [**Google Sites][41]** [1]: http://www.dickpountain.co.uk/ [2]: http://www.dickpountain.co.uk/home [3]: http://www.dickpountain.co.uk/home/blogs [4]: http://www.dickpountain.co.uk/home/biog [5]: http://www.dickpountain.co.uk/home/computing [6]: http://www.dickpountain.co.uk/home/photo-gallery [7]: http://www.dickpountain.co.uk/home/zen-brush-paintings [8]: http://www.dickpountain.co.uk/home/cool-quotes [9]: http://www.dickpountain.co.uk/home/materialism [10]: http://www.dickpountain.co.uk/home/music [11]: http://www.dickpountain.co.uk/home/materialism/sampling-reality-book [12]: http://www.dickpountain.co.uk/home/computing/byte-articles [13]: http://www.dickpountain.co.uk/home/computing/byte-articles/limits-of-computing [14]: http://www.dickpountain.co.uk/home/computing/byte-articles/oberon-f [15]: http://www.dickpountain.co.uk/home/computing/byte-articles/parallel-course-1994 [16]: http://www.dickpountain.co.uk/home/computing/byte-articles/the-oberon-language [17]: http://www.dickpountain.co.uk/home/computing/byte-articles/the-oberon-system [18]: http://www.dickpountain.co.uk/home/computing/pripar-machines [19]: http://www.dickpountain.co.uk/home/computing/ruby-projects [20]: http://www.dickpountain.co.uk/home/computing/ruby-projects/maths-libraries [21]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects [22]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/creatures-1 [23]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/equation-solver [24]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/factoriser [25]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/matcalc [26]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/wordsieve [27]: http://www.dickpountain.co.uk/home/computing/scratch-projects [28]: http://www.dickpountain.co.uk/home/computing/simpleware [29]: http://www.dickpountain.co.uk/home/computing/simpleware/Download-page [30]: http://www.dickpountain.co.uk/home/music/a-sad-canticle [31]: http://www.dickpountain.co.uk/home/music/automusic [32]: http://www.dickpountain.co.uk/home/music/bela-bartok [33]: http://www.dickpountain.co.uk/home/music/just-plain-wrong [34]: http://www.dickpountain.co.uk/home/music/just-plain-wrong-1 [35]: http://www.dickpountain.co.uk/home/music/spotify [36]: http://www.dickpountain.co.uk/home/photo-gallery/flickr-top-200 [37]: http://www.dickpountain.co.uk/system/app/pages/sitemap/hierarchy [38]: https://www.google.com/a/UniversalLogin?continue=http://sites.google.com/site/dickpountainspages/home/computing/byte-articles/the-taos-operating-system-1991&service=jotspot [39]: http://sites.google.com/site/dickpountainspages/system/app/pages/reportAbuse [40]: javascript:%3B [41]: http://sites.google.com