Portable MODULA-2-based realtime operating system

Portable MODU LA-2-based realtime operating system Steffen Hauptmann and Gunter Reinig explain the design decisions behind a new operating system to support MODULA-2for automation software

As in general soRware engineering, the increasing and unsatisfied demand for automation software has focussed attention towards the portability and reuse of software. In this context severe challenges are offered by soRware components with high quality requirements, such as the capability for multitasking, hard timing conditions, high (forecastable) reliability, as well as for components with direct access to hardware and system software. With the realtirne operating system XMod an attempt has been made to design such a system that is portable and, to a certain degree, independent of its environment. A portable software development methodology has been developed based on MODUtA-2. Using this approach it was possible to implement XMod for different microprocessor classes (Intel, Zilog) without extensive additional effort. A similar approach was used to develop high-level language device drivers and a high-level language symbolic realtime debugger. microsystems

realtime operating systems

MODULA-2

The progress of microelectronics producing more reliable, faster, more powerful and less expensive computers and other automation devices has boosted the rapid spread of process automation to many branches of business. This has resulted in an increasing, and until now unsatisfied, demand for realtime software, due to the individuality of each automation project. From the viewpoint of a small university subdepartment with R&D activities in the automation of small and medium processing plants as well as experiments and tests on the reuse of programs and software components, there is significant potential for higher software productivity. In this context, methods and tools are needed to produce long life, high quality (correct, understandable, efficient etc.), highly portable Technische Universitat Dresden, Sektion Mommsenstrasse 13, 8027 Dresden, GDR

Informationstechnik,

and adaptable realtime software by automation (not informatics) specialists, incorporating the work of graduate and postgraduate students. Obviously a uniform programming language would simplify this task. Considering other high-level languages (e.g. PASCAL,PEARL), MODULA-2was found to be a suitable choice due to its potential for applying methods of modern software technology (modularization, abstraction), its teachability (ease of learning), its universality, and last but not least, the availability of compilers/programming systems for the target computers (Z80 and i8086- based PCs and PDP-11-compatible minicomputers). The following MODULA-2concepts were used: • The module concept for structuring the operating system kernel, for specifying the user interface (abstract data types to implement nearly all of XMod's objects and functions), for isolating the kernel's environment dependences (memory map, address arithmetic, interrupt architecture, timer handling) in a separate module comprising only 3% of the overall code size of the kernel. • The coroutine concept for implementing the operating system tasks by means of MODULA-2coroutines, for processor-independent implementation of all dispatcher operations and for the, to a large extent, processor-independent interrupt handling. • The low-level programming concept for implementing hierarchical, multitasking exception handling and to avoid any assembler code parts. None of the then available realtime operating systems (RTOS) supported MODULA-2, SO the decision between interfacing an existing RTOS with MODULA-2or building a proprietary MODULA-2RTOS was made in favour of the latter, aiming at portability. For MODULA-2realtime applications a portable module library XLib was established, comprising approximately 60 modules to be used as components of modular software systems, during the development of the MODULA-2 RTOS XMod.

0141-9331/90/03186-05 © 1990 Butterworth & Co. (Publishers) Ltd

186

Microprocessors and Microsystems

While several sequential programming tools can also be used in realtime programming and testing (editor, compiler, library management) additional means are required, with a realtime debugger being the most urgent need. This paper conveys some insights, experiences and conclusions from designing and implementing the above tool and module system for realtime software, with the emphasis on portability issues.

SOFTWARE ENVIRONMENT AND TOOLS To facilitate use on PDP-11-compatible computers the original RT11-MODULA-2 system of ETH Zurich, Switzerland, was adapted to the operating system RSXl 1M, and completed with the portable system library XLib (see below). Its user interface and speed were improved; the compiler was adapted to the language revision1. On Zilog zg0-compatible computers Borland's Turbo-MODULA-2 was used, and for Intel 8086-based computers Jensen & Partners International's Top-Speed-MODULA-2 was used. To support centralized maintenance and improvement of the software, cross systems were developed; the PDP-11-M2-system is available completely under MSDOS, while the Z80-Turbo-M2 is provided under MS-DOS by means of the EM80 emulator. These cross systems provide a means of producing and maintaining large software systems using the most convenient environment (16-bit PCs in this case).

BASIC CONCEPTS OF A PORTABLE SOFTWARE TECHNOLOGY Ideal machines The technology of portable software is based on the concept of 'ideal' machines 2'3, often called 'abstract' machines. This idea was extended and realized by means of MODULA-2.An ideal machine is defined by a MODULA-2 definition module. The projection of the ideal machine onto a real one is performed by the corresponding implementation module, the real machine being represented by means of MODULA-2, the underlying operating system and by the computer resources directly attached (Figure 2). In contrast with the above approach, a decomposition of the ideal machine into several smaller ideal (sub)machines is proposed. Due to the rapid development of computer hardware it does not seem to be appropriate to

define a complete (forever) set of ideal machines. Therefore the principles of extendability and variability of the ideal machine as well as the 'application-specific' machine are introduced. The concept of the 'application-specific' machine provides access to the special resources of a real machine for a certain application. A general set of ideal (sub)machines cannot provide access to the special resources often required in automation projects without violating the principle of portability (the proposed applicationspecific machine can be understood as an applicationlimited extension of the ideal (sub)machine set (Figure 1)).

'Portable" specification Specifying the ideal machine turned out to be the main problem in following the above approach. In addition to the question of the specification formalism (a formalized verbal specification notation is proposed) the semantic design of an ideal machine is a complex, challenging, creative task which should reconcile the following conflicting requirements: • The feasibility of projecting the ideal machine onto the required target machines. • Provisions for efficient implementation. • Compactness and orthogonality of the interface. • Conformability to the application (avoidance of unnecessary a priori limitations). To maintain a well structured set of ideal (sub)machines, restrictive regulations (methodical, personal) are necessary whose 'local' evasion for special applications is possible by the principle of the application-specific machine. The verification of a new ideal machine is supported by the tool T providing a dialogue-controlled test-editing cycle to verify the fulfillment of the specification stipulations.

Libraries The library concept can be considered as a generalization of the module concept, i.e. libraries provide functions (export) and are based in their turn on functions of other libraries (import). The lowest abstraction level is represented by the total set of ideal (sub)machines which can be considered as a uniform library (of course, implementations of this library are individual to each real machine). On the other hand, implementations of further libraries using the ideal (sub)machines are independent of the real machine, i.e. portable (abstract portable machines).

Application

Tools

Portable libraries

Ideal (sub) machines

Real machine

Figure I.

General software structure

Vol 74 No 3 April 1990

Application specific machines

Several versions of ideal and application-specific (sub)machines exist for different real machines. These versions often have many common parts, so it is reasonable to derive from these versions a so-called 'master' version. For this purpose the master versions are provided with additional notations to define versions and to mark version-specific module parts (Figure 3). The tool XVer supports this approach. XVer appears as a portable pre-

787

Exception

String

I/O library

handling

Maths library

ConvN, convR,

Complex,

T,W,

matrix,

Stopwatch,

TIO, InOut,

Exceptions, e r r o r messages

General

Test tools

processing

chars,

...

tools

Scanner, sort, random,

. . . . . . . . . . . . . . . . . . . . . m

r a

W i n

m e

o u

s

t

F

L

D i

s P o u

K e ly

I

n

e s

E

x

t C o m m a n d

C

,

o u r

S

o u n d

T e r m F u n c t

M

C

a

o

t h

n s t

i

I

__:._

... Computer independent elements

of MODULA-2

Module system and low level components of

MODULA-2

Real machine ( h a r d w a r e and operating system)

Figure 2. Set of ideal (sub) machines ( . . . . . machine ( )

) and its relationship to the portable library ( - - - )

processor, integrated in the usual turnaround cycle (editcompile-link-test). To support the management of complete libraries the tool XLib was developed to provide the following functions: • create/delete a library • output library-specific information • include/exchange/exclude modules in/from a library to test and remake consistency • copy a library • derive documentation fragments from the module specification of a library • manage version-dependent libraries

I

The main goal was to obtain a realtime operating system which would enable automation software to be developed in MODULA-2for different computers. The development of XMod began from the realtime kernel MODEB 4. Major improvements and exchanges were made in the methods of interrupt handling, exception handling, dynamic memory management, object management and in the realization of the timedependent functions. Additional provisions were made to integrate support functions for a run-time debugger. Furthermore, a realtime file system, compatible with MS-DOS structured discs, was built. Further drivers for CRT displays and general-purpose keyboards were developed. The CRT-driver realizes a semi-graphic virtual window concept.

188

]

I

i

Portable

Other

portable

libraries

I/O l i b r a r y

Uniform interface (definition modules) Versions of the set of ideal (sub) (implementation modules)

machines

V.3 V.2

PORTABLE REALTIME OPERATING SYSTEM Goals

Application

and to the real

V.1

oEM-comput15"" ers with XMod

I BM-PC-compatibles

with MS-DOS PDPI l-compatible computer with

RSXI I M

Figure 3.

R ~ a ~ aeI ~

machines

Management of versions

Microprocessors and Microsystems

management using the working space assigned to the process, as in LogiTech-MODULA-2)? • Should IOTRANSFER (instead of TRANSFER) be the only way of transferring from a process activated by IOTRANSFER (as implemented in Turbo-MODULA-2)?

S t r u c t u r e of X M o d

In accordance with the software technology described, XMod is constructed upon a set of ideal machines, comprising the linguistic attributes of MODULA-2(including the concept of coroutines and I/O-transfer), an ideal machine for dynamic exception handling, Frames, and an application-specific machine. The latter is characterized by linear main memory organization, linear address arithmetic, a multistaged priority controlled interrupt system and a realtime clock (Figure 4). Currently it can be realized efficiently on the class of actual target computers (i8086-based) and amounts to about 3% of the total XMod code.

These four examples from four different software suppliers underline the need for a more exact semantic description of these (and other) linguistic elements to limit the individual interpretations. (In the authors' opinion the above questions should be answered 'No'.) Experience with XMod has illustrated the possibility of implementing the coroutine concept with an efficiency sufficient for medium realtime requirements. In the available MODULA-2implementations, problems of efficiency arise from

MODULA-2 as an ideal m a c h i n e

• (too) long periods of interrupt masking (the main problem!) • long-winded management of process description blocks • unnecessary transformations of interrupt masks • testing the hardware configuration within the process switching

The task management of XMod uses the procedures N EWPROCESS,TRANSFERand IOTRANSFERimplemented in the module SYSTEM, and is also able to appoint priorities to modules, including such priorities which are higher than those of hardware interrupts. In this way all the basic requirements of the XMod dispatcher concerning processor multiplexing and the management of interrupt tasks can be realized. Some questions arose from the somewhat fuzzy semantic description of the MODULA-2functions mentioned above and by inefficient implementations of these functions. Among others the following questions arose:

However, it should not be overlooked that hard realtime requirements (short response time to interrupts, high frequency interrupt sequences) exclude complete context exchanges as required by the process switching. In these cases special solutions (high-speed interrupt handling mechanisms, assembler programmed) are needed: Although some other problems - - like address arithmetic (how to deal with structured addresses), interrupt masking by short instruction sequences, indivisible access to global variables (e.g. is access to a cardinal variable indivisible?) - - can be hidden by means of the applicationspecific machines, serious problems of efficiency occur immediately due to the procedure calls that are necessary. Therefore it would be desirable if a language for realtime applications supported such a minimum of functions, including their exact semantics.

• Can a MODULA-2implementation be called 'complete' if the coroutine concept is missing (e.g. TaylorMODULA-2)?

• Is it possible or necessary in creating a process (NEWPROCESS) to inherit some parts of the context of the calling process (e.g. interrupt mask by Top-SpeedMODULA-2)?

• Shall a process at the moment of its creation automatically obtain certain resources (e.g. local memory

Application program

Realtime kernel application interface

Highlevel rea I time debugger

Applicationspecific drivers

Synchronization :

Kernel functions:

XSemaphores XMailboxes XRegions XDeviceSignals

XScheduler XExceptions

r-

I I I I I I

.

.

.

.

.

Portable 110 l i b r a r y

Timing functions: XClock Drivers (discs, keyboard

.

...)

XDispatcher: Data structures, list management, processor multiplexing XManager : Object management

MODULA-2 runtime system Hardware (CPU, RAM, realtime clock, discs, process I / 0 ,

Figure 4.

keyboard...)

Structure of the realtime operating system XMod

Vol 14 No 3 April 1990

"/89

Run-time system

CONCLUSION

Due to the separation of all I/O operations from the language, MODULA-2requires only small run-time systems which are quite independent of the environment, thus providing opportunities for OEM applications often working without a complex operating system. Unfortunately most MODULA-2compiler producers make no use of this facility. The following features are considered necessary for OEM applications:

The implementation of the RTOS XMod is an example of how to use the technology. Some fuzziness of the MODULA-2 language definition, especially within the coroutine concept, caused difficulties in providing portability. Nevertheless, XMod is highly portable, not least due to the introduction of an ideal (sub)machine for exception handling. The proposed MODULA-2software technology (including XMod) is being used to realize configurable software for PC-based process control operator stations and MultibusI-based process control operator stations and Multibus-Ibased front-end computers, for the automation of experiments as well as to develop further tools, among these a high-level realtime debugger XDeb (currently under 'field' test). Portability costs additional effort which is justified if long-life software (programs and component libraries) is required for a heterogeneous hardware environment. Portability forces clean, well structured programming, thus improving software quality and reuseability. In the further development of high-level languages attention should be given to support realizations that are more independent of their environment.

• delivery of all run-time system source programs to the customer • division of memory segments for code and variables by the compiler and linker (including their assignment to customer-defined addresses) • avoidance of 'self modifying code' These requirements are fulfilled, for example, by the TopSpeed-MODULA-2 system.

Exception handling In realtime high-level languages such as ADA or CHILL supporting static exception handling, an exception (e.g. division by 0) causes a transfer from the region containing the reason for the exception to the corresponding exception handler. If there is no special exception handler for that region the exception is propagated to higher level program regions until a handler is found. MODULA-2 does not provide static exception handling (although it is offered, e.g. by Borland in Turbo-MODULA-2, as a language extension). Starting from the RT11-MODULA-2 developed at ETH Zurich, attempts have been made to integrate an exception handling concept dynamically using library modules. An improved and comprehensive application of this concept was developed by Maier4. From the viewpoint of reuse and portability, two problems occur with the solutionS: • The implementation requires extensive modifications of the run-time system. • The interfaces provided are highly dependent on the underlying computer (context data). This concept has been improved, aiming at an ideal (sub)machine which could be easily realized with any MODULA-2 system on the market. Another result used in XMod is the module Frames exporting four procedures and a variable of the procedure type TYPE Frame; PROCEDURE Frame 0: Frame; PROCEDURE CalIFrame (proc: PROC; VAR errCode: CARDINAL); PROCEDURE RaiseFrame (frame: FRAME; errCode: CARDINAL); PROCEDURE RaiseFrameAsync (process: ADDRESS; frame: FRAME; errCode: CARDINAL); VAR RTSRaise: PROCEDURE (CARDINAL); Independence from the type of computer is achieved by the separation of the procedure Frame to determine the identification of an exception handling region before opening this region by Callframe. (Thus the manipulation of computer-dependent context data is avoided.) However, both calls shall occur within the same procedure.

190

REFERENCES 1 Wirlh, N P r o g r a m m i n g in M o d u l a - 2 , issue 3 SpringerVerlag Heidelberg, FRG (1985) 2 Barringer, H, Capon, P C and Phillips, R 'The portable compiling systems of MUSS' S o f t w a r e Pract. Exper. Vol 9 No 8 (1979) pp 645-655 3 Theaker, C I and Frank, G R 'MUSS-a portable operating system' Software PracL Exper. Vol 9 No 8 (1979) pp 633-643 4 Maier, G E E x c e p t i o n s b e h a n d l u n g u n d S y n c h r o n i s a t i o n Springer-Verlag, Heidelberg, FRG (1985) Steften Hauptmann studies in the Department of Automation Technology at the University of Technology of Dresden, GDR, where he is now finalizing his doctoral thesis on the portability of (realtime system) software. He has developed MODUU-2 toolsthat are widely used in the GDR. His research interest is modern software engineering.

Gunter Reinig studied control engineering at the Institute of Technology in Leningrad, USSR. He wrote his doctoral thesis on optimal computer control of a distributed parameter system(for ammonia synthesis). For 13 yearshe designed and implemented computer-based control systems for petrochemical and refinery processes at the Combined Petrochemical Works of Schwedt (GDR). In 1982 he became associate professor for process computer technology at the University of Technology of Dresden. He has published severalpapers on conceptualizing control systems for large process plants. His main technical interest is in applying modern software technology to 'automation' software, with special effortsto promote MODULA-2in the GDR.

Microprocessors and Microsystems