AN INTRODUCTION TO MTS (PDP-11) RTL Reference: 91 DATE: 21 Feb 1978 Copyright: Imperial Chemical Industries plc, 1978, Natron Software Maintenance Ltd, 1994 Notes: * The original of this MTS document (ref: RTL91) was published internally by ICI in 1978. * This version was created, under the terms of their licence arrangements with ICI, by Natron Software Maintenance Ltd in October 1994. The only significant change for this version was to remove an description of an example MTS system which was felt to be too specific to the process control industry to be of general interest. Also, one or two comments relating to developments since 1978 have been added - these are indicated by the use of square brackets (i.e. [...] ). * This version of this document may be distributed without restraint, provided that: - no charge other than reproduction costs is made for providing copies of this document, - this document is distributed complete and unchanged. * Any comments or queries relating to this document should be addressed to Natron Software Maintenance Ltd by email on rtl2@natron.demon.co.uk, or by fax to +44 (0)1904 631450. 1 BACKGROUND AND PHILOSOPHY OF MTS MTS was conceived as an integral part of the project which produced the RTL/2 language itself, in order to satisfy the need for an operating system suitable for use in small computer applications for real-time process control and data collection in both laboratory and full scale production situations. Although designed as a complete range of systems aimed at a variety of hardware configurations, its development and scale of usage reflects the changes seen during the last few years in the mini-computer marketplace; the availability of low cost plug-in memory stimulating the implementation of larger systems. Thus in early MTS systems the emphasis was on a compact no frills operating system occupying a minimum of memory in the run-time machine. Later systems relaxed this constraint in order to provide facilities which allow the software engineer to cope more sensibly with some of the problems which arise during on-line operation. However, efficient use of available memory and run-time speed of response with a minimum system overhead remain the primary MTS design objectives. MTS is available as a collection of software modules, written mainly in RTL/2. This immediately gives all the advantages which were explicit criteria for the design of RTL/2 itself - simplicity, security, flexibility, efficiency and natural re-entrancy. These modules and the multi-tasking strategy which they implement are therefore machine independent. The MTS systems which are described in this document are intended for use on the PDP-11 range of mini- computers manufactured by Digital Equipment Corporation, but the use of a high level language like RTL/2 means that they could easily be adapted to many other makes of computer if and when an RTL/2 compiler becomes available for those other machines. A few MTS modules are written in PAL-11A assembler language, or contain PAL-11A code sections, and are therefore machine dependent. These are typically primitive interrupt handlers or device drivers which interface directly to the PDP11 hardware. Such parts of any operating system would have to be rewritten to make use of the machine architecture of any new computer which was to support MTS. It must be emphasised at this point that MTS is not an operating system; it provides the software tools necessary to construct an operating system. This is a fundamental distinction between MTS and a normal computer manufacturer's operating system which is generally supplied as a "black box" to which user software must be interfaced. MTS source modules can be tailored to suit a specific application, by the software engineers responsible for the project, at the RTL/2 level prior to system generation. The distinction between system and user software is often blurred in MTS because both are written in the same language (RTL/2) and system and user modules are linked together in a similar way. Special MTS linkers are used as an integral part of the system generation process in order to preserve the security and integrity of the run-time system. They perform detailed cross-reference and internal consistency checks and pick up many trivial errors (such as ENT/EXT [global definition/reference] mismatches) which can be difficult and time consuming to locate during commissioning. The user is therefore free to concentrate on removing logical programming or design errors in the application dependent software. In order to aid the description of MTS systems, various levels have been identified which relate to the hardware which the systems are designed to support. These levels are not rigid and many features are common to several levels. Modules normally designated to a particular level can often be used on other levels, either off-the-shelf or with a small amount of user editing. This flexibility is part of the general philosophy of MTS which gets the user directly involved with building precisely the operating system required to do the job. At the same time, the levels which have been identified allow the casual user to construct a "standard" MTS system relatively quickly. The standard levels of MTS, in order of increasing complexity, are MTS-1, MTS-2, and MTS-3, with the final category being subdivided further into MTS-3M, MTS-3D, and MTS-3G. Each level is discussed in detail in a later section. Features which are common to all levels included: * standard RTL/2 error recovery (cf. document ref: RTL4), * RTL/2 standard stream i/o support (cf. document ref: RTL5), * various MTS primitives for performing real-time operations, * MTS library modules which include maths routines such as log, sine, etc; whilst features which differ between the various levels are: * detailed start-up mechanism, * task creation, * input/output (not stream i/o), * system generation and in particular the linking stage. 2 MTS TASK GENERATION All MTS systems (other than MTS-0 which consists of a single task only) are organised on a two level task structure. The first level responds directly to hardware interrupts and are called hardware or H-tasks. The second level comprises a number of tasks which operate in a more convenient and less hardware specific environment which is created by H-Tasks - these latter are known as software or S-Tasks. Both types of tasks may be user provided, although in general all H-Tasks will be available in terms of standard MTS modules and almost all the user provided software will form the basis of, or be used by, S-Tasks. Unless explicitly stated otherwise, the word "task" will always refer to an S-Task throughout the remainder of this document. 2.1 H-Tasks MTS uses the interrupt hardware in a simple fashion. Every interrupt causes direct entry, via a few words of hand-coded linkage, to an H-Task specific to that interrupt. Each such task is executed wholly at a high hardware priority so that no other interrupts may break in, other than certain error traps. H-Tasks are assumed to start on interrupt and terminate completely at its end, so that no local data is remembered from one "life" to the next. Thus all interrupt response tasks are mutually exclusive and may share a single common stack. In most cases control reverts to the S-Task which was interrupted on the completion of a hardware interrupt response. In cases where the interrupt may imply a change of S-Task, such as the expiry of a user-specified time delay, the hardware task calls an S-Task selection procedure to change linkage so as to interrupt the current S-Task and run another one. Examples of H-Tasks are: * input device interrupt servicing, * disc interrupt servicing, * clock interrupt servicing, * TRAP instruction servicing (the alternative SVC ["supervisor call"] procedure call in RTL/2 is implemented on the PDP using TRAP). The H-Tasks when taken together are known as the Executive. They are collectively responsible for providing a convenient software environment for the S-Tasks. They provide the time-critical parts of the required response to any interrupt and typically run for between 100 micro-seconds and 10 milli- seconds; other less time-critical parts of a response are provided by S-Tasks with which H-Tasks communicate. H-Tasks may be programmed in RTL/2 apart from a small amount of standard interrupt linkage. They reside in memory permanently, except in exceptional circumstances. 2.2 S-Tasks The Executive described above provides a more convenient environment for RTL/2 tasks than does the basic hardware, by implementing a task control system which supports the set of S-Tasks. There may be up to 256 S-Tasks directly under the control of the Executive, each with an individual priority and each with its own stack. S-Tasks can run independently of each other, unlike H-Tasks which are mutually exclusive. The Executive will always ensure that the highest priority S-Task currently active in memory is the one actually being executed. In this environment tasks may make use of a suite of standard procedures, most of which cannot be used by H-Tasks. These procedures include: * S-Task scheduling and control procedures (which communicate with the Executive); * text i/o device control procedures; * text i/o format procedures; * disc storage i/o procedures; * mathematical procedures. These procedures, and certain data areas provided by MTS for each task, comprise the on-line interface between normal user tasks and MTS. They are however largely written in RTL/2 and may be added to and/or modified if this is appropriate. On larger MTS systems (MTS-3), S-Tasks may be arranged either to be memory- based or to be disc-based. As the names imply, the former use code and data which reside permanently in memory (except possibly for a private overlay scheme arranged within a task) while the main program material for the latter resides on disc except when the task is running. Apart from the obvious difference in response time between the two types, they are identical and the same facilities are available to both. The S-Task priority scheme is also applied to the roll-in / roll-out of disc based partitions. A partition may contain program code and/or data, and one or more partitions may be associated with a disc based task. It is the responsibility of the Executive to ensure that all the partitions required by a particular S-Task are loaded into memory before the task can run. In all MTS-3 systems, partitions can be loaded and deleted on-line, and S-Tasks can be created and "killed". Most S-Tasks are user supplied, although there are a few which provide standard MTS facilities such as error reporting. Each S-Task has a status as follows: GO - running - pending (higher priority task also has GO status) NOGO - stopped - suspended - waiting (for an event flag to be set) - securing (waiting for a facility to become available) - delayed (for a specified time interval) The highest priority S-Task in the GO state will normally be executed until: 1. an external interrupt occurs which causes a higher priority task to regain the GO state (as a result of the H-Task servicing the interrupt); 2. it puts itself into the NOGO state by calling a task control procedure which implies it is waiting for time to expire or for a signal from another task (which may be either an S-Task or an H-Task) - when its need is satisfied it will return to the GO state and will runs as soon as priority allows. Note: in MTS-3D and MTS-3G, equal priority tasks will be "time-sliced" with a frequency which may be controlled by the user. In all other MTS systems there is no such thing as "equal priority", since tasks with numerically the same priority will effectively have different priorities depending on their position in the system's task control tables. 3 TASK CONTROL FEATURES 3.1 Timing S-Task timing is affected by the use of various DELAY procedures. The basic timing interval is governed by the frequency of the system real-time clock interrupt and is usually 1/50 second. Convenient MTS procedures are available to allow a task to delay for longer periods of time (i.e. seconds or hours) or to read, reset, and synchronise itself with the real-time clock. 3.2 Events S-Tasks communicate with each other (and H-Tasks communicate with S-Tasks) by the use of events. These can be thought of as the software analogues of hardware interrupts. Any S-Task or H-Task may SET an event, which is then remembered by MTS on behalf of all tasks in the system. Any S-Task, but not an H-Task, may WAIT for an event to be set. The task will then be suspended until the event is set. Events are reset (or cancelled) on behalf of each task by either a wait operation or by calling the procedure RESET. The use of events is the normal means of communication between H-Tasks and S-Tasks. A time-out may be imposed on a wait operation if required by calling procedure TWAIT instead of WAIT. Events are known by number and are allocated at system generation, except for certain standard events which are reserved for use by the system. 3.3 Facilities A software flag known as a facility is used to represent the allocation of a software or hardware resource which has to be shared by more than one task. This may be a physical peripheral device or a data area shared by several tasks. It is the responsibility of all tasks wishing to use a shared resource to SECURE the appropriate facility before they use the resource, and to RELEASE it again afterwards. Note that the system does not trap unsecured access to a resource. If a task attempts to secure a facility which is already secured by another task then it is placed in a suspended state. When a facility is released it will be allocated to the highest priority task (if any) which is attempting to secure it. Facilities may not be used by H-Tasks. A limit may be imposed on the length of time a task is prepared to be suspended whilst trying to secure a facility by calling procedure TSECURE instead of SECURE. Facilities are known by number and are allocated at system generation, except for certain standard facilities which are reserved for use by the system. 3.4 Interrupt handling All external interrupts are routed via the PDP-11 interrupt vector to the appropriate H-Task in the Executive. There is an H-Task for each source of an interrupt. When an H-Task is required to pass on information to an S-Task, an event is set to inform the S-Task that the interrupt has occurred. In order to allow S-Tasks to share common data with H-Tasks without interference problems, S-Tasks may also call an interrupt lock-out procedure, LOCK, which temporarily inhibits all external interrupts until UNLOCK is called. Under lock-out conditions no H-Task can run, neither can any other S-Task. Interrupts thus inhibited are delayed rather than lost, but this feature must be used with care so that interrupts are not prevented for so long that the system response to external stimuli is impaired. [NB: a variant of MTS for embedded systems (called SMT+) contains additional executive functions that could be incorporated back into MTS; these include: * asynchronous message passing between S-Tasks (with or without time-outs); * synchronous message passing between S-Tasks (always with time-outs); * additional event handling (wait for next occurrence of event, test current event setting, set event for specified task only); * task control (start/stop a task, get/change a task's priority). ] 4 IMPLEMENTATION OF RTL/2 SYSTEM STANDARDS All MTS systems support the standard RTL/2 stream i/o mechanism, and therefore a suite of procedures suitable for the input and output of numbers and text in a variety of formats is available. The way in which physical devices are selected for i/o operations and the detailed mechanisms used for driving different peripherals vary from one level of MTS to another. In all cases the primitive stream i/o interface defined by the procedure variables IN and OUT in the SVC data brick RRSIO (see document ref: RTL5) is maintained, although the means by which procedures are assigned to IN and OUT will vary. MTS systems support the standard error recovery mechanisms described in document ref RTL4. In all levels of MTS, the default error label terminates a task after ensuring that no system facilities are left secured by the task; the default error procedure is null. The detailed action taken by the standard "fatal" error procedure RRGEL varies between levels, although in all cases the final stage is equivalent to obeying GOTO ERL, where ERL is the task unrecoverable error label. RRGEL may store error diagnostic information to be printed by a special system task. In MTS-1, which is designed for small applications where memory space is at a premium, a minimal version of RRGEL is available. 5 CHOOSING BETWEEN DIFFERENT LEVELS OF MTS The previous sections have introduced those features which are common throughout the whole range of MTS systems. This section highlights the differences between the various levels, with a view to choosing which level is most appropriate for a particular application. In most cases the choice of system will be influenced by two main factors - the hardware available and the total size and complexity of the application itself. The balance between the two is obviously a matter for the system designers but this section attempts to indicate how MTS copes with both. MTS-1 This is designed for small dedicated multi-task systems using typically 8K-16K words of memory and no disc space. Emphasis has been placed on keeping the size of the system down to an absolute minimum, and therefore i/o to or from devices is carried out directly and independently and the start-up mechanisms are crude. The typical size of an MTS-1 system is 1.5 - 2.5K words. MTS-2 Again this is intended for memory-based systems, but probably with more memory available, up to 28K words. This system still places considerable importance on using a minimum of memory but contains many features which enable the intelligent handling of the practical problems which occur with on-line running. Input/output devices are controlled centrally so that traffic can be re-directed at the users' request in the event of a peripheral device failure. Automatic logging of certain error conditions detected by the system is provided. The start-up and automatic restart facilities are considerably more sophisticated. MTS-2 also provides a simple job stream in which to run RTL/2 programs at the lowest priority, the programs being loaded from paper tape. This facility is not intended for the casual user since the system does not attempt to perform comprehensive checks on what is being loaded. MTS-2 can occupy between 3.5K and 6K words of memory. MTS-3 is designed for larger systems, particularly those requiring more than 28K words of memory. As there are three different ways of obtaining this additional space, three corresponding sub-levels of MTS-3 are defined. In each case there is a fixed memory area containing H-Tasks, control routines, i/o routines, common procedures and data, and possibly some S-Tasks. Outside this fixed area, S-Tasks reside in partitions and may communicate either through the fixed memory area or through attached partitions. On-line loading, creation and killing of tasks are standard features. MTS-3M is for memory-based systems utilising the Memory Management Unit. The fixed memory area and the partitions are each allocated a specific virtual address area. Housekeeping of Active Page Registers when attaching partitions and on interrupt is done by the system. MTS-3D is for disc-based systems without memory management. The system rolls partitions into and out of a transient memory area on a priority basis. S-Tasks may have tree-structured overlays within partitions. The system ensures that all partitions attached to an S-Task are in memory before allowing it to run. A disc file package is included in this version. Both MTS-3M and MTS-3D will typically occupy 8K to 12K words of memory. MTS-3G combines the facilities of MTS-3M and MTS-3D, being a disc-based system which utilises the memory management relocation capability to provide a more efficient and flexible partition allocation algorithm. A disc file package is included in this version. MTS-3G will usually occupy up to 12K words of memory. MTS-0 is mentioned last because it is not really a multi-task system. It supports a single-task environment which is suitable for testing individual tasks in an off-line manner and for running "utility" programs such as compilers in a stand alone manner. The i/o facilities in MTS-0 are similar to those in MTS-1. It occupies about 1K to 2K words of memory. All the systems can support a large range of peripheral devices as well as varying numbers of tasks, events, and facilities. The figures for the sizes of the systems are somewhat vague because of the modularity of MTS and the scope for potential user editing. It is also possible to produce different versions of the RTL/2 control routines. These perform such functions as procedure entry and exit housekeeping, array bound checking, and various arithmetic functions such as floating-point arithmetic, variable type changes (e.g. Real to Integer), etc. If applications do not require Real arithmetic then the floating point routines can be omitted with a considerable saving in memory usage. Alternatively, the control routines can be tailored to take maximum advantage of certain PDP-11 hardware features such as the EIS and FIS units or the FPP co-processor. The RTL/2 compiler for the PDP-11 can also be used to produce in-line code to exploit some or all of these features. 6 THE MTS BUREAU SYSTEM The Bureau System is an optional extension to either an MTS-3D or an MTS-3G system. All of the programs associated with this facility are disc based, apart from one small memory-resident module (normally less than 20 bytes). It introduces the concept of Utility Tasks, which are distinguished from other system S-Tasks by the way in which they are created and by the fact that they are of finite duration - i.e. they run to completion. In all other respects they behave as normal S-Tasks and during execution are subject to the usual MTS task control scheme. They are used for running batch type programs such as the PDP-11 RTL/2 compiler, the MTS linkers, the PAL-11A assembler, text editing and disc file management programs, etc. The essential parts of the Bureau System can be broken down into: 1. The Activator Task A single dedicated S-Task which responds to user entered keyboard requests. Its function is to initiate and run a utility task identified by a two-letter mnemonic, e.g. CO for the compiler. This task may also be used to run a sequence of utility tasks without further operator intervention, using a user prepared set of instructions written in a simple job control language and stored in a disc file. 2. The Channel Interface This consists of a suite of procedures which form a convenient system-independent i/o interface for the utility tasks. Physical devices are identified by a letter (e.g. D followed by a file name for a disc file) and a utility request for input or output is translated into a question on the system console to which the user may respond with a device code letter, etc. 3. The Utility Programs These may be supplied as part of the Bureau System or they may be user written. Once invoked by the Activator task, each utility runs as a normal system S-Task. Specific task numbers are dedicated to the running of utility tasks at system generation; this enables the usual task termination message to be suppressed. The Bureau System is available as a set of modules in a similar way to MTS itself. These can easily be incorporated into an MTS-3D or MTS-3G system to provide the Bureau capability which could exist in parallel with S-Tasks and other system items which are performing real-time operations. This would provide an extremely powerful MTS system complex in which utility programs are used to perform the on-line functions of dynamic task/program creation and deletion, etc. in a fully integrated manner. Various "ready built" Bureau Systems are available which support no real-time functions but which provide a complete RTL/2 program preparation, development, and testing facility. They include a standard set of utility programs to which others may be added by the user, and a standard set of peripheral devices. Other peripherals can easily be added on-line. The Bureau System is now in widespread use and in particular supports all the programs which are necessary for building MTS systems. 7 GENERATING MTS SYSTEMS Initially MTS systems are available as collections of modules, most of which are written in RTL/2 with a few being in PAL-11A. The first stage is to select the level of MTS required and identify the interfaces between it and the application dependent tasks and routines. These must then be written, of course. All RTL/2 modules must then be compiled, using the RTL/2 PDP-11 compiler, into PAL-11A text. This stage will also produce cross-reference information which contains descriptions and positions of all the ENT and EXT code and data bricks in each module. The modules are then "joined together" by submitting this information, together with similar information for hand-coded assembler modules, to the appropriate MTS linker program. This uses the cross-reference information to check that all inter- module references are consistent and, assuming there are no discrepancies, supplies addresses for them. The PAL-11A text can then be assembled into absolute binary by the PAL-11A assembler (listings produced during assembly refer to either physical or virtual memory addresses as appropriate). The final stage is one of loading the absolute binary into the target computer, using either the DEC Absolute Binary Loader in small systems (MTS-0/1/2) or a special purpose MTS loader for the MTS-3 range. The whole generation process may be carried out on any machine which supports RTL/2 and need not be performed on the target computer. Typically, IBM 360/ 370s or PDP-11s which support the MTS Bureau System are used. [The MTS development tools also run on PDP-11s under RSX-11M; we could rehost these to run on PC/MS-DOS systems without any great difficulty. We (Natron) also have an alternative assembler/linker/loader combination that currently runs under RSX-11M and VMS and which uses the more familiar post-assembly linking process - we may be able to adapt this for MTS; if so, we can certainly port the tools over to a PC or any other convenient system]