DPS Technical Brief

 1. Introduction
 DPS is the multi-task OS, which comes with our computer products.
It supports multiple windows with various graphic functions, has an
object access system, as well as external type learning conventions,
and feels comfortable even on small systems (the Nukeman 226 has 1 Mbyte
of RAM).

 The DPS file system allows 32-bit file sizes, can work with non-file 
mode devices, and can transparently (though somewhat slower) access
Microsoft formatted disks. Files are accessed via the registered file
access functions in nearly all cases; that is, DPS keeps a list
of files which are open and prevents reservation conficts (making
a file publically avaiable, i.e. r/w accessible for multiple tasks,
is also possible - this is how, for example, directories are accessed).

 Because its initial application  was for measurement and control
purposes, DPS has well defined hardware access standards and offers
many readily available objects (e.g. "device", "device_parameter",
"nukebus_module" etc), thus minimizing the programming overhead for
incorporating new hardware into the system. 

 Task switch is done using rotating priority with increment every
time a task loses the arbitration; this guarantees it will eventually
win. Once a task wins the arbitration, its priority is preset back to
its basic level (as spawned or set by other means in the task
descriptor).
 The time slice can be set as low as 2 milliseconds; beyond that, 
all tasks waiting for some event can ask the scheduler to give control
to another task immediately.

 System memory is dynamically allocated/deallocated (using worst-fit
strategy) in clusters (cluster size in DPS 1.1 is 1 kbyte).
 Applications are given a mechanism to declare allocated memory blocks
for swapping while not accessing them (this works even on systems
without an MMU).

 Disk space is also allocated using worst fit strategy, which yields
(of all known) the least medium fragmentation (a lot less than with
the most widely spread first fit strategy). Medium space is described
by a bit-per-cluster, the file layout being stored separately
from the CAT (Cluster Allocation Table), which allows 32 times shorter
cluster under the same circumstances as a system using 32 bit FAT
would allow.

 The script language allows access to DPS external objects and recursive
calls (a script can call itself), and also allows retry and resume
from the point/level of abort. The script processor is available as
an external object to any application which wants to use it.

 All programs written so far are reentrant/position independent, which
allows running multiple copies of the same program code as multiple
tasks, which is automatically done by DPS.

 System programmers who will need access to exception vectors are
given the convenience not to think how many times and by which task
a vector has been swapped - they can just use the registered swap
and restore function, which takes care of restoring the right value
to the vector at the right moment, optionally automatically upon
killing a task which has swapped vector(s).

 Device driver programmers are given means to find their way to
the device descriptor from the related interrupt handler (i.e. device
drivers are also completely position independent).


 
 2. Operation

 Upon system start, DPS goes through the following steps (of user
interest):

 - processes the setup.syst file, which is used to set certain
   system parameters (e.g. the time slice) and to load as densely
   as possible selected device drivers,

 - spawns the "win.com", which is the task dealing with mouse actions,
   manual window limits change/signalling, keyboard polling, input (from
   mouse and keyboard) distribution to the input owning task etc.,

 - spawns the "shell.com", which, in turn, executes the "turnon.bat"
   command script, upon whiches termination waits for user commands.

 DPS applications run as independent tasks. The shell program is the
program which starts other tasks as applications (either from a command
line input or as a result of a menu selection); in order to start a
new task, it does the following:

 - calls the "xload$" function, which checks if the respective 
   program module is resident in memory and loads it if it is not, 

 - calls the "spawnn$" function, which:
   - allocates the user level data memory (also called user DSCT),
   - allocates the task's system DSCT, at the top of which 
     it places certain task unique variables and sets the system 
     stack pointer just below this area,
   - connects the task to the parent's (i.e. the shell's) common DSCT, 

 - prepares the standard input, standard output and standard error
   (stdi, stdo and stderr) I/O nexuses (an I/O nexus is a more 
   general form of a file) for the new task and registers it for
   access into each;

 - calls the "start$" function, which places the new task among those 
   which are given control from the scheduler and waits the task 
   to exit or be aborted (from another shell using the "kill" command or 
   killed because it did some illegal access etc) unless having been told 
   to start the task in background, in which case it comes back immediately.

 A task, after having been spawned, can choose to allocate for itself
another common DSCT and spawn other tasks (this is how the nuvi
program operates, for example); the new group of tasks, connected to the
same common DSCT - which (except for its header) is used as the tasks
wish - is sometimes refered to as a "process".

 Not all the code a task needs to execute must be in the program module
it was started with. A task may call named functions from specified
files (default suffix being .plm). When such a function is called, the
respective file is loaded as a program module (if not already there),
and control is given to the location specified by the function name
the way a subroutine is called. Upon return from the function, if there
are no more tasks connected to this module, it is discarded. 
(Many such functions are readily avaialble in \syslib\ - like "menu",
"dpsfsrch" - file search from a window etc.)

 One way for the tasks to communicate with each other is by sending
signals/messages. (This is how, for example, the mouse actions are
distributed from the "win" task to other tasks). To send a signal,
a task calls the "sign$" or "signto$" function; then, with some more 
system created data being passed, a predefined point of the target
program module of the task being signalled to is called. How the
signal is received then is up to the code of the receiving task; if
it is our "qstd" code, for example, it will place the signal on a
queue in the receving task's user DSCT and return; the receiving task
will eventually find it there and process it.

 When a task exits (either alone or being killed by another), the 
following is done:

 - the resources taken by the task and denoted so in its history
   record are released, possibly one or more exit subroutines
   are called, if declared (at least one if the task owns open
   windows),

 - all I/O nexuses to which the task was registered are "left" - that
   is, the task is unregistered and, if the nexus (file) has no more
   tasks registered to it, it is closed,

 - the history record is processed on a second pass,

 - the task's user DSCT is deallocated,

 - the task is unregistered from its common DSCT, which is deallocated,
   if no more tasks are connected to it,

 - the task is unregistered from its program module, which is removed
   (deallocated) if no oter task is connected to it,

 - the task's system DSCT is deallocated and the task is removed from
   those being given control by the scheduler (i.e., the task descriptor
   is released) - the task is dead.

 3. DPS External Objects 

 The DPS external object access system is simple and straight forward
-  an object is something with which certain actions can be done -
how they are done  depends on the object. When a program wants to
do something with an object, it points to it, indicates the action
and calls the "do$" or the "qact$". Every object is of some type 
- that is, it is a kind of some other, known at the point of learning,
object; the basic type of object is "something". Doing an action 
with some object is done the same it was done with its "prototype"
object unless declared differently. 

 External object designation follows a standard format - 16 bytes 
(usually used as ASCII text) designate the type. The actions are designated
by 8 bytes each (again, usually used as text); object descriptors are
kept on a linked list, where search links are different from the type
links; this allows the most frequently used objects to be checked 
first, regardless of their type or moment of learning.

 To teach DPS what a new object is, a program has merely to attempt an
action (possible or not) with such an object. As it is not found on the
linked list, a file (with a name made of the first 8 alphanumeric characters
of the object type) with a .type suffix is searched first in the 
calling task's spawn directory (the directory where the program module
was loaded from), then in \wwdir\, and the object descriptor(s) found
in this file is (are) put on the list; then, the "install" action is done
with the object which initiated the search (the "something" type "install"
action returns without doing anything), and finally, the requested
action is attempted. Type search is recursive; that is, if a type
found in a file is not known at this point, another search is initiated
before installing the new type.
 On boot time, DPS 1.1 always installs the following types:

 - "something", with the following actions defined:
   - "install" - does nothing,
   - "create" - create such an object in memory,
   - "remove" - remove such an object from memory,
   - "readobj" - read (learn) a new object - see the paragraph above,
   - "getsize1" - used by "create" to determine the size of the
     object being created,

 - "memory_block" , which is "something", and is used by DPS to keep
   object descriptors into.

 If the "create" action is done with "something" (e.g. by using the
"make" statement from a command script), the "object_segment" type is
learned; it is a kind of memory block with some more encapsulation
data, and makes sure that the created object, which is inside this
"object_segment", can be locked for access, properly removed and/or
located during garbage collection procedures etc.

 The "show" action is reserved for DPS usage - it is done with
objects in a sequence being processed by the "xwseq$" function,
which allows displaying of a sequence of both DPS internal
and external (the latter were discussed above) objects.

[Contact us] [Home]