608 lines
30 KiB
Markdown
608 lines
30 KiB
Markdown
---
|
||
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'
|
||
|
||
---
|
||
[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
|
||
|