Computing with REAL-TIME SYSTEMS Volume 2 Proceedings of the Second European Seminar University of Erlangen - Nürnberg Computing with REAL-TIME SYSTEMS Volume 2 Proceedings of the Second European Seminar University of Erlangen - Nürnberg

Edited by 1.C. PYLE AERE Harwe/1 and P. ELZER University of Erlangen

TRANSCRIPTA BOOKS

30 Crr1ven Street, Strand, London WC2 (t b) Publisher: S. Chomet

© Copyright P. ELZER and 1. C. PYLE where not otherwise noted Printed in the United Kingdom by Shortlands Press Ltd, London

2 CONTENTS

5 PREFACE

GENERAL CONSIDERATIONS ON REAL-TIME PROGRAMMING

9 Experiences with languages for real-time programming D.R.FROST

15 Standard software versus high-level languages R. C.HUTTY /P.W. HEYWOOD (Speaker)

19 Which programming languages for minicomputers in process control? V.HAASE

23 The influence of the structure of high-level languages on the efficiency of object code G.MUSSTOPF

29 Efficiency of programming in higher-level languages H.MITTENOORF

34 Workshop on general considerations on real-time programming

BASIC DESIGN PRINCIPLES OF OPERATING SYSTEMS

39 Adaptive operating systems H.WETTSTEIN

43 Description of operating systems in terms of a virtual machine H-P.ROST

46 Interrupt handling in real-time control systems R.BAUMANN

53 Choosing a standard high-level language for real-time programming M.G. SCHOMBERG, and P.WARD

57 Use of high- and low-level languages in a real-time system J.STENSON

61 Workshop on basic design principles of operating systems

COMPONENTS OF REAL-TIME SYSTEMS

65 Basic supervisor facilities for real-time I.C.PYLE

3 70 Software aspects of the UMIST hybrid J. N. HAMBURY

75 Process scheduling by output considerations G. McC. HAWORTH

81 CALAS70 - a real-time operating system based on pseudo­ processors G.HEPKE

84 A dynamic adaptive scheduling scheme for a real-time operating system H. HERBSTREITH

87 Workshop on components of real-time systems

SPECIAL SYSTEMS AND SYSTEM FEATURES

91 Simulation du deroulement logique de programmes de commande de spectrometres h. neutrons Ph. BLANCHARD, Ph. LEDEBT, and M.TAESCHNER

96 An implementation of a virtual CAMAC processor A. LANGSFORD

99 An implementation of the assembly language and program assembler for a virtual CAMAC processor V.J.HOWARD

106 System software real-time testing aids W.E. QUILLIN

112 Testing and diagnostic aids for real-time programming E.C.SEDMAN

115 Real-time programming using a real-time language of intermediate level B.EICHENAUER

121 Workshop on special systems and system features

123 CLOSING ADDRESS

125 AUTHOR INDEX

4 PREFACE

Following the First European Seminar on Real-Time Programming at Harwell in April 1971, this Second Seminar was held at Uie University of Erlangen, Nürnberg, in April 1972. lt was organised by P. Elzer of the Physikalisches Institut of the University, assisted by Mrs Brehm, with further help from K. Pelz and P. Holleczek. As at the first seminar, special periods were allocated for 'workshop' discussion sessions covering particular areas, and notes on these discussions are included. (The absence of identification of the speakers in these discussions is deliberate, to emphasise that speakers' views are personal and do not necessarily represent those of their institutions.) The papers presented and workshop notes were prepared for publica­ tion by P. Elzer and I. C. Pyle.

5

GENERAL CONSIDERATIONS ON REAL-TIME PROGRAMMING

Chairman: Prof. Dr R. LAUBER

7 EDITORS

IAN C. PYLE, MA, PhD {Cantab) has been working with computer software since 1956, particularly concerned with programming systems (Hartran on the ICL Atlas Computer), multi-access sys­ tems (HUW on the IBM 360 computer at Harwell), and multi-computer command and control systems. He is now Professor of Computer Science at the University of York.

PETER ELZER, MA {Erlangen) has been working with computers since 1966, at the Physics Institute of the University of Erlangen. His early work concerned the development of a programming system for application to nuclear physics experiments. He was one of the initiators of the PEARL project and is now leader of a PEARL implement team at the Physics Institute. Since 1971 he has now been involved with the LTP� project, of which he is now the European Chairman.

TRANSCRIPTA BOOKS Experiences with languages for real-time programming

D.R. FROST General Electric Co, Phoenix, Arizona, USA

Publication rights reserved to D.R. Frost and the General Electric Company

At General Electric's Process Computer Opera­ A good programming tool: tion in Phoenix our product consists of real-time 1. Gives the programmer a vocabulary that process data acquisition and control systems, matches his application. with applications including the automation of power 2. Takes care of hardware plants, power distribution, refineries, . chemical. - storage allocation plants; such processes as discrete parts manu­ - controlling peripherals. facturing, steel making; production of cement, 3. Provides non-ferrous metals, paper, textiles, and others. - standard algorithms For these automation systems we provide the - data formats computer and process input;output. We frequently - character codes. provide analysis and programming as well. Since 4. Promotes good design, and allows good economics dictate that we will get no more money design to be maintained as the system for this service than it is worth to our customers, gradually evolves. profitability depends upon our skill in keeping 5. Has self-contained debugging aids, which programming costs down. This paper is about - make mistakes less likely our attempts to lower costs through the use of - make error correction more reliable. higher level programming languages and applica­ 6. Gets rid of 'patches' (machine-oriented tion packages. I will discuss: program corrections] and the dependence 1. What we expect from higher level languages on knowledge of the computer which 'patch­ and application packages. ing' requires. 2. Our specific experiences with these various 7. Aids maintenance of a design as the applica­ types of languages and application packages tion changes. and how successful they have been. 8. Aids maintenance of code as errors are 3. Where we are headed. found and corrected. 4. Lessons we have learned. Good design is probably the biggest cost saver in software production, and good tools encourage good design. An excellent example is the suc­ Expectations cessful language COBOL, which forces the pro­ grammer to define and document his data base. The whole rationale for using higher level (1 suspect that this is actually more a key to languages and application packages is to sa ve sys­ COBOL's success than is its natural English­ tem costs through lowering programming costs. language-like syntax.) There have been many successful tools for various Successful languages and application packages other computer applications: FORTRAN, ALGOL, such as the ones mentioned exist in the compara­ COBOL, LISP, various report generators, sort ti vely orderly world of scientific and business packages, and simulation languages are just a few. data processing. They fit their applications very All of these tools have a common objective: to well. FORTRAN is a good language for mathema­ produce machine-independent source programs. tics and logic. The vocabulary of COBOL Machine independence is often equated with consists of business data processing terms in portability between computers. Yet the truly common use lang before computers. The environ­ important facet of machine independence is not so ment of a sort generator package is orderly files much portability; of more importance, it allows of data. But the term 'real-time programming' the user to implement his solution without all the causes many of us to think simplistically. lt computer-related clutter that gets in his way. makes us believe we will find a single, ultimate To a problem solver this clutter is overhead, with tool for 'real-time programming'. But real-time all of that word's connotation of cost - and he is applications are just as diverse as those for right. He wants independence from the computer. which we use LISP, FORTRAN, and report

9 generators. As a result, we are finding and will In spite of these shortcomings, FORTRAN is in continue to find a multiplicity of 'best' tools for use today. In some companies (and some applica­ real-time systems, depending on the particular tion areas) it is used a great deal. This is applications. possible because of various attempts which have been made to remedy FORTRAN's shortcomings. Good tools for real-time programming must These various attempts ha ve resulted in a provide the same advantages as do existing proliferation of FORTRAN dialects and extensions. successful tools for other applications: We have two ourselves, one predating the 1. Independence from the computer. FORTRAN ANSI standard, the other based on it. 2. A problem-oriented vocabulary. 3. Encouragement of good software design. The real-time problem is solved through provid­ ing a real-time operating system outside of Let us now look at some of the tools that have FORTRAN. System functions or subroutines are been used by employees and customers of General made available to the programmer for interroga­ Electric's Process Computer Operation. ting time, which is kept by the operating system.

Data types are augmented by allowing various forms of bit arrays and providing operations to Our experiences work on them.

Data communication problems are also handled FORTRAN - a semi-success through various extensions to the language. In one case we changed the meaning of labelled Soon after FORTRAN swept to supremacy as the COMMON to allow more than one common area. earliest and most used mathematical program­ Named system variables are another useful ming language in the United States our customers technique. wanted to use it to program their process appli­ cations. In the early days there was considerable Program organisation is dependent on the avail­ naivete about the usefulness of FORTRAN for able operating system. A program with its own real-time programming. lt 'seemed natural' that subroutines is usually (but not always) considered its acceptance for mathematical applications a program segment to the operating system. would be duplicated immediately in process con­ Special system subroutine calls can be used to trol applications. Yet even now, more than ten schedule other program segments. years later, its use is light compared to assembler language. Without considerable work Input/Output is a very troublesome area. it would have been a total failure (and was for FORTRAN I/0 is based on such a rigid approach some time). that many improvements have been attempted, but most have proven unsatisfactory. For example, First, let us look at its shortconiings: the idea of sharing a peripheral is foreign to 1. Real-time - FORTRAN has no capability FORTRAN. This causes a problem when very of recognising the passage of time or of large operating logs must be collected and stored, responding to real-time data arriving at then put out on a typer without being interrupted unpredictable intervals and in varying by other output requests to the sarne typer. volumes. 2. Data types - it does not handle large num­ There is a hopeful development: as a result of bers of logical variables efficiently. the Workshops on Standardisation of Industrial 3. Data communication - COMMON storage Computer Languages held twice yearly at Purdue (as used in FORTRAN) is monolithic: it University, a standard for FORTRAN extensions provides total communication or none, is being worked out. Although the semantics of which works against good program design. some of these extensions are operating-system­ Besides, data bases are seldom small dependent and cannot be standardised, the syntax enough to fit into one COMMON pool in main can. lt is predicted that this effort will be memory. successful. 4. Program organisation - FORTRAN's sub­ In our own shop the use of FORTRAN is mostly routine method does not provide control limited to power plant performance calculations. linkage or data communication between seg­ I believe the problem here is that trading off ments operating under a real-time operating savings in program production against an system. increase in program size and hardware cost is 5. Input/Output - Formats fit neither the difficult to 'sell '. Hardware costs are easy to needs of process input nor communications calculate, but software costs are nebulous; it is with operator consoles and other specialised not always easy to demonstrate the advantages to devices. financial management.

10 Therefore, I have to consider FORTRAN as coding of programs, which is certainly a being relatively unsuccessful. small part of the programming job. (Our study reported positively on the language mostly because of savings in coding time; PERCON and SCANCON - app/ication package failures we just did not then realise what a small part of the total work coding really is.) PERCON (periphera.l control) and SCANCON 4. We failed to do a good job of training the (process input control) were two application programmers in the intelligent use of the packages intended for our first process control language. computer with core memory, the GE-412. Our lesson here is that coding aids are not PERCON was really no more than a typical peri­ enough, and training is essential. A macro pheral 1/0 package. SCANCON was a table assembler failed later for exactly the same driven process scanner much like that now in reasons. SEER. These two packages never got off the ground. After considerable design work they were killed MACRO assemblers - abortive attempts before cocling began; thus we will never know their merits. They failed because they were con­ Macro assemblers have been frequently proposed, ceived and designed by a group that was not and one was implemented. lt was written by an actually involved in the application programs; application programmer for application program­ and this is fatal. Analysis and design work must mers, which is an approach that should lead to be done by those who will use the package. There success. Yet it was little used. lt failed for the are two reasons: same reasons that COOL failed. lt did not do 1. They probably know better what to do. enough for the programmer, and reassemblies 2. Even when they do not know, you have a frequently bypassed the macro processor, and nearly impossible political job in selling there was no training of any consequence. the package to them.

SEE R - a big success COOL - a language that failed As power consumption in the United States has Even in the early days it was obvious to us that mushroomed we have been providing a great FORTRAN was not the right language for process many process computers for power plant monitor­ computer programming, so we tried our hand at ing and control. An application package for inventing one. COOL (Control Oriented Language) power plant monitoring, SEER, has been our was a dialect of WIZOR, a little known (but excel­ most successful tool for saving programming lent) language for system programming available costs. lt is a system of functional modules for on the GE-225 general-purpose computer. data scanning, logging, alarming, and console Although it looked like other computer · languages, input and display. lt also includes support control of almost everything remained in the hands routines for performance calculations. lt pro­ of the programmer. lts strong point was that it vides a base system which can easily be expanded gave the programmer a good syntax for operations to include further plant monitoring as weil as on scaled fixed point and logical variables. The plant control. compiler translated COOL into assembly language Several factors contribute to its success: for input to the assembler. 1. All steam power plants are pretty much The language was greeted with enthusiasm by alike; thus we had an application narrow our application programmers (a study bad been enough to fit an application package to. made of the language before the translator was 2. Programming and hardware both are nearly implemented, both for technical and political always purchased by power companies from reasons), and it was immediately used. But it a limited number of traditional instrumenta­ fell into disuse quite rapidly. What had gone tion suppliers; thus programming has not wrong? Several things: been fragmented among many teams of 1. The compiler existed on our general­ programmers. purpose computers only, which made 3. SEER evolved slowly, starting as individual language patching in the field a necessity. programming jobs where we carried pro­ 2. With assembly language accessible to the gram design and code from one job to the programmer, re-assembly without recom­ next. We thus learned to understand the pilation was tempting, and this quickly made application very weil. the COOLstatements obsolete, indeed mis­ 4. lt was invented by the same group which leading. was going to use it. 3. Since COOL statements quickly became 5. The programmers using it knew the soft­ obsolete, they saved time only in the initial ware as well as the application, and could 11 thus use it intelligently. immediately runs into a semantics problem. The 6. Because of our heavy participation in the phrase has two meanings: market, our approach has had good accept­ 1. Digital (as opposed to analog) control of a ance from major engineering firms that process element in any kind of application. design plants for the utilities. 2. An application package for control of contin­ 7. We waited until we had ade facto near uous processes only, in which analog con­ standard before we standardised the appli­ trollers are replaced with digital control­ cation package. lers. 8. A team of programmers with power plant The latter definition is used, because it is the experience was assigned to write the application for which our ddc packages have been standard, guaranteeing political accept­ written. ability as well as continuity of knowledge, Direct digital control was originally conceived experience and technology. as a money saver. lt seemed that considerable Although our exact costs cannot be divulged, savings in hardware cost could be realised through it can be said that, working in ratlos, our first replacing analog controllers with digital control­ plant monitoring system took about 18 units. lers, moving control calculations into the compu­ Before the final standardisation effort, the time ter. Since this has turned out not always to be was down to 3 units. We can now, with our true, ddc has not become the control method that present standard application package, produce one its advocates had desired äiia expected. Indeed, in a single unit of effort. (In all cases this does interest appears to be waning. not include special unique application software. ) In addition to a good many special ddc systems, We are now developing a SEER for the GE-PAC we have produced two generalised ddc packages; 3010 based on experience with three previous one a large application package for general use by process computers, this time confidently without customers who, unlike electric utilities, usually the trial-and-error approach. do their own application programming. The other is a special package for a specific .customer who has us to do his programming for him and TASC - an unsung hero has given us considerable repeat business. The former has not been particularly success­ Although monitoring power plant operation is quite ful: either deficiencies in our package or lack of standard, control, especially in sequential opera­ success of the concept (large ddc systems) might tions such as start up and shut down of the boiler be the reason. I suspect the latter. and turbine, is less so. The "special" ddc package has just recently Early in our history one of our programmers evolved to a state where it is becoming standard. invented a sequential control language called We have realised the same kind of cost savings TASC (for Tabular Sequence and Control). TASC on recent systems as we did with SEER just is a typical interpretive system with before the final standardising effort. 1. A sequential control language. 2. A translator of TASC statements (one-to­ one) to a compact code. Other Utility App!ication Packages - evolution 3. A simple interpreter which, based on TASC statements, selects subroutines for execu­ Just as SEER gradually standardised and the tion. special ddc package is on its way to becoming 4. A library of subroutines which actually standardised, other utility packages (for monitor­ effect the control actions specified in the ing power transmission networks to provide sys­ language. tem security and for economic dispatch and power The language and translator have remained generation control) are also evolving towards a much the same functionally through the ten years Standard. of their existence and through several computers. For power transmission network monitoring The control subroutines usually require some (called SCADA) we have moved so far that we are rewriting from job to job. now 'standardising' the package. Economic dis­ This is called an unsung here because it has patch and power generation control packages will never had much publicity to our customers or probably reach the same stage within one to two even our own management. lt continues to be one years. We are already realising savings through of those valuable tools that no one much knows re-use of design and code. We are confident that about except the programmers using it from day true standardisation will lower our costs per to day. system even further.

Direct Digital Contra/ - success or failure? 8/CEPS - a successfu/ supervisory control system

When discussing 'direct digital control' one BICE PS is a large system for supervisory control 12 [ where process variable setpoints are sent to ous system implementation languages that are analog controllers (or to a ddc system)] of. being invented. continuous processes. It provides the engineer Earlier the necessary attributes for success with forms which he fills out to describe measured were stated: variables and control loops; it also provides a 1. Machine independence (as it was defined simple language for programming his control then). algorithms. Its files are available to programs 2. A problem-oriented vocabulary. for further optimising and control calculations. 3. Encouragement of good software design. (These programs are usually written in Good implementation languages allow one machine FORTRAN.) It was designed in cooperation with independence when one wants it, but let one get the same company that had previously been instru­ as close to the hardware as one wishes when one mental in the design of IBM's PROSPRO system needs to. Although an implementation language for the same application. We have delivered it to cannot give 'the best' problem-oriented vocabulary several other customers as well as to the original (since it will be applied to diverse problems), it customer. can at least give a better algorithmic vocabulary In my opinion, its success may be credited to than FORTRAN, and a good implementation the fact that supervisory control still remains the language will encourage good program design. main reason for using a computer on a continuous We are working on one now. process, and that this application package fits supervisory control well. (Note, however, that one can expect application packages like this to Lessons we have learned increase system overhead. The laws of hardware/ software trade-off apply.) To sum up, our nearly fifteen years' experience in searching for better programming tools has taught us the following: What next? 1. An application package can be a real money saver where there is a large enough population of From the evidence of our own successes and fail­ jobs for the package. ures it appears that application packages have 2. Application packages are best developed by saved us considerable money, while new languages the people experienced and actually involved in the have done little for us. application. Yet members of this group must be Actually, the dividing line between languages set aside and be dedicated to final standardisation and application packages is hazy at best. Thus independent of any one specific application. the elusive problem-oriented 'languages' that the 3. Do not expect standards to be final. They industry has been looking for are in truth taking are subject to evolution. the form of application packages like those we 4. The ideas for any languages designed for have been discussing. Consider the important use by application programmers should come characteristics of both: from them. As a poor second choice, there must 1. Machine independence. be a careful, ear ly study conducted by the system 2. A syntax for describing the problem solu­ programmers to discover the application pro­ tion that grammers' real needs. This study serves two - fits the problem purposes - it increases the probability of techni­ - the problem solver can use with ease. cal success and it helps to 'sell' the tool. And Although the syntax used with an application make no mistake, the acceptance of a tool by package does not look like a language (i. e. it is those destined to use it is one of the most critical not algorithmic}, I maintain that the differences requirements for success ! are only syntactical and that we should not worry 5. The programmers who will use a tool must about what form our successful 'language' takes. be thoroughly trained in both the appllcation and It is the benefit that counts. the software itself. Therefore, my conclusion is that for applica­ 6. FORTRAN with appropriate extensions can tions where standardisation is feasible, we at help if one is willing to make the necessary General Electric will continue to define applica­ hardware/software tradeoffs. Yet it is not really tion packages to lower programming costs. the right algorithmic language. Unfortunately, not all applications can be 7. None of the candidates (and there are many) standardised, usually because the number of for the 'right' algorithmic language has yet proved similar applications is too small to make it eco­ successful (that is, none has bec�e a widespread nomical. For these we must continue to search standard). for an algorithmic language better than FORTRAN. 8. Tools that help merely in the coding stage FORTRAN is merely a stopgap until a really good of programming are not worth the trouble. algorithmic language comes along to take its 9. Any language should have support so that place - and there are candidates coming from all its translation can occur at the application site. directions. At present we are looking to the vari- Otherwise much of the expected savings fail to

13 materialise. For information on some of our application packages see: 10. Good software design vs. poor software - SEER System (GEA 8465) design will make more difference in programming - BICEPS Summary Manual (GET 3559) cost than the language selected (except where the - GE-DDC Summary Manual (GET 3558) language fits the application particularly well). also available from General Electric in Phoenix. 11. An application package must be modular; considerable effort should be made to separate For discussions on the functional requirements for Industrial Computer Systems the relatively stable elements from those that will see: likely change from job to job. - Minutes of the Fifth Workshop on standardization of Industrial Computer Languages, also available from the Purdue Laboratory for Applied Industrial Control (see above). This work has been summarized in CURTIS, R.L., 'Functional requirements for industrial For FORTRAN see: computer systems', Instrumentation Technology (November 1971). - American standard FORTRAN - American Standard Basic FORTRAN For further discussions on the applicability of FORTRAN for both available from: process control see: United states of America standards Institute, 10 East 4oth street, - FROST, D.R., 'Fortran for process control', Instru­ New York, N.Y. 10016, mentation Technology (April 1969). USA. - 'Clarification of FORTRAN standards - initial progress', For a good survey of process-oriented languages see: ACM Communications, Vl2(5), (May 1969). - PIKE, H.E., Jr., 'Process control software', January - 'Clarification of FORTRAN standards - second report', 1970 Proceedings of the IEEE, a special issue on com­ ACM Communications, Vl4(12), (October 1971). puters in industrial process control. This same issue contains many good articles, including For the Purdue proposed extensions see: SCHOEFFLER, J.D., and TEMPLE, R.H., 'Real-time - Minutes of the Fourth Workshop on Standardization of language for industrial process control' - (a proposed Industrial Computer Languages (pp. 71 ff) available algorithmic language). from Purdue Laboratory for Applied Industrial Control, For General Electric's FORTRAN see: Purdue University, Lafayette, Indiana 47907, - GE-PAC 4000 Process FORTRAN Language Manual USA. (PCP 122) There have been minor amendments which have not - GE-PAC 4000 FORTRAN IV Language Manual (GET been published. This work will result in an Instrument 6051) Society of America Standard. both available from: - Also obsolete in some of the details rut adequate to General Electric Company, give you a feel for the style of the extensions is Utility and Process Automation Products Dept., KELLY, E.A., 'FORTRAN in process control: Technical Publications, standardizing extensions', Instrumentation Technology 2255 W. Desert Cove Raad, (May 1970). Phoenix, Ariz. 85029, USA.

14 Standard software versus high­ level languages

R.C. HUTTY GEC-Elliott, Borehamwood, England

(Presented by P. Heywood)

1. lntroduction designedto satisfy the software requirements for a particular application area. Application stan­ The purpose of this paper is to assess the merits dard software is developed only once but can be of using Standard Software as against a High­ used in any computer system required to perform Level Language for application programming. the same kind of function, e.g. a DDC system. Although some of the points made in this paper Normally the only application programming work are applicable generally to all fields of computing, required is the initialisation of parameter values they are intended to refer mainly to the computing relevant to a particular system and a requirement field of process and industrial control. specification of the parts (usually optional) of the software required for the system.

2. Definitions 3 . Problem-orientated languages are similar to high- level languages except that they are defined As the terms 'standard software' and 'high- level for a specific field of application, e.g. sequence language' are often misused, their meanings, as control, and are machine-dependent. The soft­ used in this paper, will be outlined. ware for a system is written using the statements of the language. However, the set of statements available is restricted and designed only for the Standard software narrow field of application. lt is therefore not likely to be useful for any other field of applica­ Standard software is that software which is tion. designed, coded andtested once, butuse d, with little or no alterat..,.m, in more than one computer system. Standard software for a particular com­ High /eve/ /anguages puter is normally developed by the computer manufacturer. Standard software falls into three High- level languages are used for one-off applica­ categories: tion programming. High-level languages are now 1. Basic standard software. replacing assembly languages for one-off applica­ 2 . Application standard software. tion programming. The advantages and disadvant­ 3. Problem-orientated languages. ages of using high- level languages instead of assembly languages are not discussed here. 1. Basic standard software refers to standard High- level languages, e.g. FORTRAN and software which is designed for a particular com­ ALGOL, and their statements are designed for puter range and is general-purpose enough to be general use. Real-time languages such as RTL used in any computer system which utilises one are included in this category. of the computers in the range. Basic standard High-level languages are not wholly general software, e.g. executives and operating systems, but are designed for very much wider fields of is used in almost every computer system. Other application than the narrow field for which basic standard software, e.g. mathematical problem-orientated languages are suitable. For routines, although general-purpose, is not neces­ example, real-time languages are designedfor sarily used in all systems. all industrial control and real-time applications, whereas a sequence control language would only 2 . Application standard software, normally used be suitable for relevant industrial sequence with the support of basic standard software, is control applications.

15 3. Specific comparisons to be specified precisely. The customer there­ fore knows exactly what he will receive and the For a comparison between the use of standard programmer who will implement the system will software and a high-level language, every aspect know what to provide. of a computer manufacturer's business, from selling to commissioning, must be considered. Programming

Marketing Standard software reduces the programming skill required. This makes the software less expens­ The marketing of systems is enhanced by the ive, more controllable and reduces the risk. availability of extensive standard software, Standard software should provide an over-all especially application standard software and software cost saving over the use of high-level problem-orientated languages. lt is possible to languages. A programmer's job is reduced when provide meaningful publicity describing the parti­ using standard software because it has been pre­ cular item of standard software and its area of defined and pre-structured. Programming may application. Potential customers are able to be just a matter of supplying data to application identify their company's requirements with soft­ standard software. ware designed to solve their own particular lt is likely that non-computer people will be problem. Standard software packages lend them­ able to 'program' a system using application stan­ selves to more illuminating advertising languages. dard software or problem-orientated languages. High-level languages can be advertised, but their Thus, engineers who specialise in the application impact on potential customers is not as great. field for which the standard software is designed can 'program' the software for his own applica­ tion, thereby providing a system which does Selling exactly what he wants it to do. Therefore, the problem created by the difference between what Standard software makes the task of selling sys­ an engineer actually wants and what a programmer tems easier. Sales teams can aim at definite actually provides is removed. market areas rather than a general area. Sales­ men are able to sell fixed price packages for some types of application standard software and Commissioning are able to communicate with the potential custo­ mers via the standard software because it is Commissioning problems are reduced when designed for the customer's application and is standard software is used because there are readily familiar to and understood by the custo­ fewer bugs in well tried and proven standard mer. software than a first-time one-off program.

Te ndering Documentation

Tendering of software systems currently involves Standard software reduces the amount of docu­ a higher degree of risk than is normal in an engi­ mentation to be produced for each -contract. neering environment and therefore anything which Standard documentation is a natural by-product helps to reduce this risk is obviously advantage­ of standard software. However, high-level ous. Estimating the software content of a contract languages provide a good degree of self­ is more accurate when standard software is avail­ documentation. able than with high-level languages. The problem of estimating storage for a system is reduced if standard software is used because a !arger 4. General comparisons amount of store is pre-defined by standard soft­ ware than languages. There are many points other than those associated Not only storage estimates, but also the man­ with each phase of a contract, which are general power required (which is often proportional to the and worth noting. storage requirements), are easier to assess because a standard software package inherently defines what is required to be done to make it Staff changes suitable for a particular system. Even if it is not possible for the whole of the software system to Staff changes during a contract pose fewer be standard, at least that part which is standard problems when standard software is used, because is likely to be estimated accurately. Standard the software system and its requirements are software enables the function of a software system capable of being well defined initially and do not

16 usually change. lt is better to 'bend' standard software than to use only a high-level language since at least some of the software will remain intact andas such be Machine dependence well proven . The bending should be performed, if possible, by the team who implemented the Standard software is usually machine-dependent software, in order to reduce the risk of errors. and, as such, is designed to be as efficient as possible, with respect to both storage and execu­ tion time. However, high level languages are Development cost usually machine-independent, so when one of these languages is required to be used on a parti­ Standard software development costs must be cular computer the object code produced by the compared with the cost of producing a compiler compiler may be unsuitably inefficient - this for a high-level language. If anyap preciable depends a great deal on the particular language­ amount of standard software is developed then its computer combination : cost will be greater than the cost of developing a compiler. Iiowever, it is usual to have available both standard software and a high- level language Suitability in order to completely cover all possible applica­ tions, andth erefore development costs are lt is very difficult to define a high-level language required for both. which is suitable for all applications within the extensive areas of application for which they are designed. For example, the inefficiencies produced by high-level languages are likely to be 5. Conclusion too large to be used as an alternative to basic standard software. However, efficiency is not lt would seem that there will always be a require­ always of prime importance. ment for high-level languages and standard soft­ Unfortunately, it is usually the case that ware because of the shortcomings of standard standard software, especially application stan­ software. Although standard software, where it dard software, does not provide exactly what is canbe used, will usually be less expensive and required for a particular application, even though involve less risk than a high- level language, it is the application is considered to be in the area only in simple applications that a system could be intended to be covered by the software. This made up completely of standard software. Hence, usually happens when a customer's requirements in most systems, standard software requires to extend outside the norm for which the software be either supplemented, or replaced, by a high­ has been designed. Where the requirements are level language. lt is importantthat a high- level not essential then it must be pointed out to the language be compatible with the standard software. customer the extra costs that are incurred by As a general rule, wherever possible, standard either 'bending' the standard software or program­ software should be used in place of high-level ming the system in a high-level language, as a languages. one-off system, as against using the standard software intact. Where the requirements are essential then there is no option but to 'bend' the standard software or to use a high-level language. Discussion

Q. In what level of programming language is your Oua!ity standard software written and specified?

The suitability of standard software depends upon A. lt is written in assembly language, and speci­ the quality of its design. A knowledge of the fied in terms of the facilities it provides (and the functional requirements of standard software is implications thereof) in assembly language terms. an important necessity before its design canbegin ; this will ensure that the software is likely to Q. How stable do you find your standards ? satisfy more applications than it would otherwise. The design of standard software should ensure A. Packages are always modified, but only that it can be easily made to fulfil the require­ slightly. ments of a particular application without redundancy. This is often currently achieved by Q. Are not modifications to standard software using a modular approach in the design of the difficult to test ? software. Tools for a good system construction facility A. Possibly so for an individual system, but not are necessary for modularly constructed software. essentially worse than testing the original package. 17 Q. Suppose ?, piece of standard software (let us A. The software S' may be eligible for standard­ call it S) is slightly bent to form something we isation, but is certainly not new standard software shall call S'. Then henceforth, is S or S' the automatically. new standard software?

18 Which programming languages for minicomputers in process control?

V. HAASE UN!COMP, 8/ankenloch, W. Germany

A B Computer involvement in industrial and scientific There is an extensive literature on real-time process control shows a very significant increase languages, but little implementation experience. in the application of very small computers. This The minicomputer has attracted few papers. We is due to the fact that hardware costs are falling, shall therefore try to express the apparent contra­ whereas the cost of designing, installing and diction between the (unpublished) feelings of com­ maintaining special-purpose systems is not puter scientists and the experience of users, becoming lower. This calls for general-purpose namely, that both kinds (small and big) of real­ electronics in measurement and control: the time computers should not be programmed in the minicomputer. This is the reason for the fact that same way, at least not using the same higher level this end of the computer spectrum is not populated language. so much by small brothers of medium- or large­ There exist special � of (real-time) pro­ scale real-time computer systems, but by special gramming languages that are especially suited for systems designed for - and in many cases by - compilation and execution on minicomputers. the engineer used to working with special-purpose They will be explained and proved as follows. control hardware. This hardware is now replaced If we look at higher level problem-oriented by a 4 to 16 K, 8- to 24-bit machine with storage special-purpose programming languages that could cycles between 0.5 and 5 µsecs, in most cases be used on minicomputers in process control, we capable of, but not necessarily equipped with, all may distinguish several groups of languages: kinds of conventional and process-control capabili­ 1. Macro assemblers. ties which medium-scale computers have as peri­ 2. So-called 'low-level' languages pherals. The whole thing costs no more than a (e.g. PL/360). special-purpose hard-wired system. 3. Real-time dialects or subsets of procedural Nevertheless, the lack of relationship between languages (e.g. R-T-FORTRAN). minis and !arger systems often causes a software 4. System writing languages (e.g. POLYP). gap between minis and midi- resp. maxi compu­ 5. Special real-time-languages (INDAC, ters. Hardware-mindedness of both designers and PEARL) which may also be based on other users, and the fact that minis are used in environ­ languages (e.g. PAS). ments which are not frequently changed, have led 6. Problem-oriented languages (e.g. fill-in­ to the development of special-purpose software the-blanks language). (instead of the special-purpose hardware that On the other hand we may lay down criteria (func­ existed before!) - nonmodular code including both tional requirements) for real-time languages: operating system and application program func­ a. Easy to use. tions. b. Machine-independent (at least, 'control­ Programming was (and is) done in some kind lable' machine-dependent). of assembly language. In the course of time, here c. Effective. and there, FORTRAN and BASIC compilers or d. Timing in 'programmer's hands'. interpreters were developed (non-real-time­ among others. We add for the mini: applicable) and the idea of indirect programming e. Executable. came up (minis were used more in changing tasks, f. Compilable on a machine with less than 16K laboratories, test-stands, etc.). As the indirect working store (no mass store). method is of little use if a !arger computer is not Everybody knows that items b. and c. (especially at hand (which is often the case if a program has in connection with e. and f. ) are contradictory. to be changed in the field), it is necessary to think We therefore have to find a compromise matching about programming languages and compilers to the lists of language types and requirements: solve real-time problems with small computers. 1. Macro assemblers are effective (c), pro-

19 vide timing- control (d) and cope with the mini­ 2. An assembly language, covering both requirements (e, f); they are not machine­ machine instructions and macro-instruct­ independent (b) and not always easy to use (ä). ions (if it is sufficient, the normal 2. Low-level languages can be designed to assembler of your machine). fulfil criteria a., c., d., e. and f., but they are lt is necessary that these two components can explicitly machine-dependent (b) and therefore, be mixed at the statement level - not only at the for example, very useful for system writing. module ( = linkage editor) level - and it is to be 3. Real-time dialects and subsets of FORTRAN provided that user-named items (data and labels) and similar languages have shown that they are can be defined in one and used in the other state­ not able to solve both real-time and efficiency ment type. problems, i.e. inherent problems of batch pro­ cessing languages (c, d). Perhaps this could be achieved, but not in mini-environments. C1 4. System-languages are sometimes claimed Since these ideas came up when a special project to be the solution for process control and any was considered (the usefulness of a process­ real-time problems. They are, in fact, but only oriented programming language to be implemented in the hands of very clever programmers. on the UNICOMP 201) some aspects of this However, ease of use (a) and timing and tasking machine will be mentioned. features are not ideal (d). UNICOMP 201 is a 20-bit machine with working 5. Newly designed real-time languages would, storage expandable up to 32K. Since the limited of course, be the best solution (if they fulfil the instruction repertoire, as far as arithmetic is functional requirements). The problem of concerned, is balanced by a great variety of generality versus efficiency can be solved for operation- and addressing-modes (system-user !arger systems, including backing storage states; literal, working store, indirect, external (INDAC, PEARL), but for minis this is not pos­ store and 'execute' operands), real-time program­ sible. The design concept has to be modified so ming can be done quite nicely. that both assembly type and procedural type A convenient macro-assembler makes use of languages are combined in a new language. 'supervisor-call' instructions, causing the execu­ Should this lead to a modular structure of the tion of a subroutine package present at runtime language itself, implementation costs could also that can be implemented as a 'firmware' module be reduced (PL/1 + PAS/1, and PROCESS­ (a fast read-only-memory). These macro BASIC, to be introduced here). instructions include both fixed point (multiple 6. Special problem-oriented languages will precision, too) and floating point arithmetic, and not be considered here, as they are no common interrupt and I/O handling instructions. For the solution for real-time problems (and in many design of a language with the desired features, cases also designed in a descriptive type: no the algorithmic part must be replaced by a com­ timing = d). mon procedural language. We have chosen BASIC for reasons of easy learnability and compilability. To improve efficiency, BASIC had to be C expanded by a data-type INTEGER (INDEX) that is If we combine the efficiency of an assembly used for counting and field addressing operations. language, handy macros for handling real-time As labels are represented by line numbers in functions (timing, interrupt-handling), and the BASIC also, the assembly type statements of machine-independence and ease-of-use of BASIC Process-Basic are allowed to have and to refer or FORTRAN - the whole of which can be com­ to integer labels. The name-syntax of BASIC is piled and executed on a mini - we obtain the not changed (for compatibility reasons), so that language we are searching for. Of course, these all names in assembly type statements that do not properties cannot be present simultaneously in consist only of one letter and one number are every language element (under our marginal con­ unique for the assembly part of the program. ditions), but we can try to have them in an additive structure. This seems to be sufficient in The three levels of Process-Basic statements the majority of-cases, e.g. one frequently needs comprise: a special algorithm for data reduction (that is present in a higher level language library), but not the I/O driver for a special device used in Level 1 (BASIC): some other installation (that has to be program­ med very efficiently). INPUT, READ, PRINT, DATA, RESTORE Input and My solution for a programming language for Output minicomputers in process control is a composite GOTO, IF, FOR, NEXT, GOSUB, RETURN, STOP, END language, the elements of which come from: Control 1. A procedural language (BASIC) that is easy DEFFN, DIM, INDEX Definitions to learn, use and compile. LET Assignment 20 Level 12 (Macros): more string handling functions, the latter real­ time macros). OUT,OTN,INP,INN,OSM,ISM,OLS,ILS,KTL,PLA,SAZ: As for the compiler implementation for small 1/0 Operations done in parallel or sequentially, machines, two philosophies are applicable. with or without formatting, using symbolic or First, for very small core size two pass systems direct addressing. are to be preferred; the object code will be punched. Certain on-line text-editing is possible, ISS,ISL,RIT: but no incremental compilation. The object code Interrupt answer definition, enable, disable. may be both relocatable and linkable. Secondly, Multiple precision arithmetic, block transfers, if one can afford to hold both dictionary and object text editing and test instructions are also code in core, one pass systems which allow handled on macro level. incremental compilation can be preferred. The object code can be either executable at once or be used as input into a linkage editor. Level 13 (machine instructions): The compilers will be very similar, as the structure is defined by the general syntax parser. Operations Modifications Directory- and code-generating routines are used as subroutines by the general routine. Certain BRI ( l oad) optimisation (in the field of space versus time­ 1 iteral UMS ( s tore) efficiency) can be performed in that the code ADD working store address ADU generator has two possibilities which can be KON (and) indirect address chosen by the programmer: more in-line or more subroutine-like code (e.g. loop-heads, if-state­ EOR X 1/0 address ERH ( + l) ments). The advantages of BASIC can be seen in VER (-l) execute the general expression definition, the name syntax (j ump) SPR sl!lpervisor call allowing a directly addressable directory and the UPS (subrout.) very clean statement type recognition. SAN jmp =O SUN jmp f 0 The type of language described here is thus a SKU jmp car =O good solution, both for the implementer (good price /performance ratio) and the user of a small All three levels of statements can be mixed line­ machine (handyness and flexibility). wise as shown in the following example:

.EQUAL. TIMER='006' device definition control statements .EQUAL. ADC1 ='5F1' on assembler level 100 FOR I=1 TO 10 110 BRI 30 ADC1 loop coded in BASIC intermixed with 120 UMS 22 I machine code 122 NEXT I .PSW. '0100' address of an interrupt routine 200 BRI 30 TIMER 210 DIV 00 333 macro instruction, time converted to 220 UMS 20 T1 secs

1. KEMENY, KURTZ, 'BASIC'. C2 2. FRÖHLICH, 'SAMMI, assembly language for The actual software (as planned) will be based on UNICOMP 201 '. the existing UNICOMP software; it will consist of operating system, compiler, linking loader, test and text-editing routines. Discussion The operating system (2 to 4K) is modular in the sense that a list-driven event (interrupt)­ Q. Why must the compiler run on the BK machine? handling routine, the device driving package and supervisor-call-interpretation macros can be A. Frequently the computer is out in the field at tailored by the user according to his special pur­ some plant, and the users will wish to be able to poses. The compile-time-0S can be different do their own program development. Also they from the execution-time-0S (the former including may not have access to bigger machines.

21 Q. Will not the advent of satellite computers alter statement optimisation. Do you accept this this? reduction in efficiency?

A. lt will still be awkward if you have to go to A. Yes, we are much happier that the program­ another computer which is remote. mer is aware of this and has to deal with inter­ statement optimisation explicitly (e.g. by use of Q. Line by line interleaving of assembly INDEX) than that he leave this to the compiler. language and high level language statements We allow a testing phase using an interpreter to implies that the compiler cannot attempt inter- give debuggingfacilities, with only tested parts of the program compiled.

22 The i,nfluence of the structure of �igh-level languages on the efficiency of object code

G. MUSSTOPF Scientific Contra! Systems GmbH, Hamburg, W.Germany

1. lntroduction The comparison of an object program, which has been generated automatically by a translator Programming languages are a means of communi­ from a high-level language, with a functionally cation between man and machine. For each of equivalent object program which has been opti­ these languages an alphabet (set of symbols), a mally written in a low-level language shows a syntax and a set of semantic rules are defined. large difference in the quality, i.e. efficiency, of Applying the syntax and semantics statements for the object programs. The size of this factor with a computer can be constructed from the symbols respect to speed or size depends also on the of the alphabet. If a language consists· of only a structure of the computer (in addition to the few simple elements which are strongly adapted reasons given above). to the hardware of a given computer, it is called For many applications this loss is rightly a low-level language. Algorithms which are to be accepted. There exist. however, apart from described using such languages must first be system software, very many problems in the field manually prepared, i.e. translated. Other of real-time applications which require that the languages have a substantially !arger set of ele­ object programs be of high quality. The ments and rules. The representation of formulae assertions in the following sections should be in such languages, for example, is that used by considered in connection with these problems. the mathematician. These languages are called high-level languages. The translation into a form acceptable to the computer is carried out by a 2. Programming languages and programs special computer program. lt is noteworthy that no measure exists for the level of a programming The classical machine and assembler languages language. lt is also important to note that an are considered here solely as objects of compari­ arbitrary number of levels exists between the two son for the quality of object programs. This extremes. section classifies languages such as PL360 [1], One of the aims of developing a program with PS440 [2], CORAL66 [3], BLISS [4], PASCAL the help of a language is to perform the computa­ [5] and POLYP [ 6]. tion defined by the program. The object program A program consists of two different kinds of as end product of the development, whether from elements. The first kind is used to describe the manual pretranslation or from automatic transla­ application (application elements), e.g. testing tion, can be of varying quality. This can be seen, measurements for critical boundary values. The for example, from the speed and/or size of the second kind is required owing to the 'general or object program. The quality of an object program specific structure of the computer' (EDP. ele­ is influenced by the quality of the translator, the ments), e.g. the specification of the lengths of language and the source program. items of information or the use of address vari­ People who program computers have the wish ables. The use of this kind of element helps the to express themselves at as high a level as pos­ translator to produce a better object program. sible, i.e. they want to use the jargon with which These two classes of elements cannot be they are familiar. The advantages of being able distinguished by the operators of operands they to do this are: contain. 1. Short training period. The minus sign in 2. Short program development time. 3. High legibility of the source text. TN - TO 4. Low test and maintenance effort. is used to represent a temperature difference, 5. Later modification easily carried out. whereas that in

23 problem oriented FORTRAN integer I, K, N; (high level) ALGOL array V AL[0:50]; PL/1 RTL I := 3 * K + V AL[N];

general computer POLYP address POINT; integer I, K; oriented CORAL 66 � LIMO16); (medium 1eve 1) PASCAL I := 3 * K + POINT:LIM;

machine oriented PL 360 variable POINT( B(32,8), A24); (low level) PS 440 integer I, K, M; � LIM(I16); POINT :=POINT+ 4 * M; I := 3 * K + POINT:LIM; Assembler lang, L R,M SLL R,2 A R ,POINT ST R,POINT Variation of level statement by statement on passage through program

Fig. 1 Language levels

AV - 4 cation B(32,8) states that the address variable is used to modify an address constant. From this should have a bit address which is modulus 32 it can be seen that one must speak not only of the plus 8. For a word machine (smallest address­ level of language but also of the level of a pro­ able storage unit is a word) with a 32-bit word gram. If address arithmetic is available in a the declaration above means that the variable is language it does not mean in general that the to be positioned into the rightmost 24 bits of a • programmer is forced to use it in his programs. word. The declaration is also interpretable for a The EDP elements of a program can be 16- or 8-bit machine. divided into three subclasses: 1. Elements which refer to the general struc­ ture of computers (e.g. data overlay). L word 1 ength 32 bits 2. Elements which refer to the properties of address: 2003 2004 a specific computer but which only influ­ ence the efficiency of the program (e.g. use byte 1 ength 8 bits of pointers as operand). L 3. Elements which refer to the properties of address: 516 517 518 519 520 a specific computer and which lead to errors (among other things) if the same source text is used when the program is L word 1 ength 16 bi ts address: 2 transferred to another computer. 400 4003 4004 Programs which only contain applications ele­ ments and EDP elements of the first class are Fig. 2 Positioning called machine-independent, those which in addi­ tion contain EDP elements of the second class are called conditionally machine-dependent and those The language elements used in the declaration containing EDP elements of the third class are above are machine-independent since the syntactic called machine-dependent. and semantic defiriition makes no reference to a This classification proves useful when the particular computer. Their occurrence in pro­ languages themselves are analysed. The position- gram elements leads to conditionally machine­ ing of information in POLYP is taken as an dependent or even to machine-independent example. The declaration: programs·. The notion machine-independence is connected with the notion transferability of variable AV(B(32,8),A24); programs. Languages like FORTRAN, ALGOL 60 defines a variable with the name AV of type and COBOL were developed in order to allow for address and of length 24 bits (A24 ). The specifi- the exchange of programs regardless of the

24 computers being used. A program was transfer­ must have a list of the names of all standard and able if it produced identical results when trans­ 1/0 procedures (e.g. in its identifier list). lated and run on two different computers. This condition is in general not sufficient for real- time applications. In addition, timing conditions (reaction time) must be fulfilled. This is, standard functions however, difficult to attain. (numerical) Another difficulty leads to similar wishes. i system functi ons system Small and medium-sized real- time computers (I/0, real-time) often have peripherals whose performance is too low and software which is not extensive enough for the development of medium and large program l systems. For this reason many users are in favour of transferring the development work onto normal user functions r variables, arrays, a large computer. This should be possible without user tables, etc. having to use a simulator. lt is mostly sufficient if the logic of the program modules can be tested on the large computer. Furthermore, it is not only possible to produce translators for such computers more cheaply, but they are also Fig. 4 F capable of accepting the full language. unctions

The program which is generated by the com­ piler must normally run under the control of an operating system. This run- time operating system need not necessarily be identical to the compile time operating system. An existing real-time system operating system is usually used, whereby inter­ software production face routines and extensions are necessary. This system often requires an effort which is half the total

Fig. 3 effort of producing the compiler. Also, adaptation causes a reduction in the efficiency of the system. This problem occurs especially with real-time If an object code of high quality is required it systems where the advantages of a universal is necessary to make use of additional aids such system are discarded in favour of the higher as general macro processors. efficiency of numerous small systems, each of which is tailored to the demands of a given appli­ cation. Thus the necessity arises of adapting a 3. Compilers language and its compiler to a given operating system. This should be possible without having For the following considerations it is necessary to modify the compiler. lt is possible to meet to say something about the structure and the this demand if a distinction can be made at the development of compilers. lt is the job of a com­ definition level between the classes of procedure piler to analyse a source text and translate it into mentioned above [ 6] . In the compiler only the a form which is directly or indirectly executable call interface need be defined. For each by the hardware. lt is useful to differentiate procedure class a different instruction sequence between those problems which are associated with for the call is generated. The number and nature 'compile time' and those which are associated of the individual standard and 1/0 (or system) with 'run time'. procedures need not be known to the compiler. A compiler must be integrated into an operat­ From the programmer's point of view, the ing system which, for exa.mple, takes over the main nucleus together with the procedures must management of data files. lt is important that the represent a unit. By this method a system compiler must be able to differentiate between independence can be achieved which, at least for various kinds of language elements (as opposed to the next few years, exists in no process control the programmer). For example, the compiler programming language, compiler or operating must normally be able to distinguish between calls system. to user procedures, calls to standard procedures and calls to 1/0 procedures. One reason for this is that often different instruction sequences must 4. The reasons for bad object programs be generated in each of the three cases. In order to make the distinction possible, the compiler lt is often thought and claimed that the reason for

25 the low quality of object programs which have been is normally left unexamined. The problem can be gen erated from source programs written in high­ sölved in critical cases only by using address level languages lies in the fact that the optimisa­ variables for which an address arithmetic is pro­ tion methods used in the compilers are not good vided. An improvement can be achieved in enough. Much could certainly be done to improve POLYP [ 6] , however, by using the vectorial these methods but optimising alone cannot solve statements which are an extension of the PL/1 all of the problems being discussed. For array cross-section principle. example, the problem of choosing between an The last example is the call of a procedure optimisation which produces a fast object program with the transfer of parameters. Procedures are and on e which produces a short object program on e of the most important aids in producing cannot be solved satisfactorily since the compiler program systems and at the same time one of the sees the source program as a static unit and has most common causes of low quality in object little or no infromation about its dynamic nature. programs. The reason can be found in the In the following considerations it will be assumed universality of the procedure concept. The para­ that the compilers considered all perform a suf­ meter list in the object program consists, with ficient degree of optimisation. Three typical hardly an exception , of a vector of pointers. The properties of program elements have been chosen possibility of transferring values in registers or which exist in languages such as FORTRAN. in special lists does not exist. The volume of In the first example the definition of informa­ instructions required for a procedure call and in tion (data) is analysed. Information types such as the prolog and epilog of the procedure is out of integer, real, boolean and string are usually proportion for short procedures. available. The information length is normally The reason is that the construction and predefined although alternatives such as double management of the parameter lists must be partly length are often allowed. In considering the generated by the compiler and partly undertaken information type boolean, which is most interest­ by run-time routines. It is completely sufficient ing in real-time applications, the question of the for critical applications if an address variable as representation of a boolean value immediately parameter is allowed. Thus the organisation and arises. Should it be represented by a bit, a byte management of parameter lists becomes flexible or maybe a short word ? The information can be and can be programmed to suit the situation. For stored so as to optimise access time or so as to example, the same parameter list can.be used optimise storage requirement. The source text for düferent procedures, or the parameter list of the program must be analysed in order to can consist of a mixture of pointers and values. determine which optimisation method should be used. Although it is relatively easy to calculate the storage requirement of a program, it is 5 Conclusion usually impossible to discover much about the effect of an access time optimisation, since the Considering the demand for language elements dynamic properties of the program cannot in for the positioning of information , address vari­ general be determined. As already mentioned, it ables, address arithmetic and address variables is also necessary, along with the type and length, as parameters in procedure calls, it can be seen to specify the positioning of an item of informa­ that the price to be paid for an improvement in tion. This is especially of interest in the case of the quality, of object programs is the necessity tables, where the elements possess various types for a better knowledge of the hardware properties and lengths. of the computer(s) being programmed. It is not, The second example is the sequential process­ however, required that the syntax and semantics ing of information. Program cycles or loops of the assembler languages in question be known. (e.g. for statement), in which rows or columns of The problems mentioned are often solved by arrays or tables are processed, are 'mostly used inserting assembler language text into the high­ for this purpose. The well known methods of level source. This, however, does nothing to optimising the organisation of the loop do not gi ve improve the legibility of the source program. the solution to the problem. More critical is the The solution adapted by languages such as Bl.JSS, access to the information which is processed PASCAL and POLYP is to provide language ele­ within the loop. The use of index registers relies ments like those discussed above which can be on the fact that the loop controlled variable is used to improve the declarations and in some incremented/decremented by a fixed constant cases which can be used at critical positions in value for each circuit of the loop, one condition the dynamic parts of the program. The use of a for which is that its value is neither directly nor second language is thus not necessary (Fig. 1). A indirectly (side effects of procedures!) altered more exact examination shows that a relatively within the loop. If a static analysis of the source small number of fixed or special positionings of program shows even a remote possibility of this information are required for a given computer or occurring, index registers cannot be used. The project. The generality of, and thus the amount sequential processing of information outside loops to be written for, a gi ven declaration can be

26 disturbing. This difficulty can be removed by This method can be used to great advantage, introducing a general control (or macro) language. together with the system procedures mentioned With the aid of a suitable library the required in Section 3, to extend the language, without 'modifications' can be made to the source text. changing the compiler or operating system, with real-time oriented function calls. lt is also pos­ modified sible, after the design phase of a project, to source source object program program construct a control procedure library (Fig. 7) so program ______.,. that during the programming phase programs can interpretative --� source progr. generative be written without special knowledgeof the com­ modification compiler puter and which can be translated into efficient object programs.

The methods described here also allow the control procedure 1 i brary development of real-time program systems using !arger computers (software production system). lt is only necessary that the required control Fig. 5 General macro processor procedure libraries be available.

mod. programming test system test maintenance

design system

Fig. 6 Project phases

macro object assembler program program macro assembler

modi fie � source source code program program generators

interpretative --- generative CG Y compiler compiler macro CG Z assembler X X library X

' macro ._, assembler y control control procedure procedure library library X y macro assembler 1 i brary Y

Fig. 7 Ful l compiler

27 1. WffiTH, N., 'PL 360, a programming language for the Discussion 360 computers', Journ. ACM, Vl5 , pp. 37-74 (1968) . 2. GOOS, G., LAGALLY, K., and SAPPER, G., 'PS440 - Q. In Fig. 1, what does the horizontal axis Eine niedere Programmiersprache', Bericht 7002 RZ denote? der TH München . 3. Inter-establishment Committee for Computer Applica­ tions, 'Official definition of CORAL 66' (1970). A. The stage during execution of a program - 4. WULF, W.A., RUSSELL, D.B., and HABERMANN, A.N., different statements may be at different levels. 'BLISS: a language for systems programming' , Comm. of the ACM, Vl4(12), pp. 780-790 (December 1971). Q. In Fig. 6 (project phases), how significant are 5. WffiTH, N., 'The programming language Pascal', Acta the relative sizes ? Informatica, Vl , pp. 35-63 (1971). 6. MUSSTOPF, G., 'Definition der Programmiersprache POLYP ' (noch unveröffentlicht) . A. lt depends on the problem. 7. MUSSTOPF, G., 'Sprachgesteuerte Modifikationen von Quell-programmen ', GI-Tagung (März 1972). Q. 1s a description of POLYP available ?

A. Only in German (see reference [ 6] ) .

28 Efficiency of programming in higher-level languages

H. MITTENDORF Karlsruhe, W. Germany

1. ldea of efficiency in computer programming languages remained forbidden (e.g. very generalized I/0 procedures, bit- and byte­ The increase in software costs as compared with oriented data-types, general data structures and the cost of the hardware devices themselves has language features for general loop-modifications). forced both vendors and users of computers to lt is only now that such extensions are being dis­ become more and more conscious of the problem cussed in conjunction with the new languages PL/1 of effective programming. Difficulties then arise and ALGOL 68. because many people use the following definitions There has been a general feeling that the refer­ side by side: ence value man-power would remain sufficient for a. Effective (i.e. as short as possible) a lang time, i.e., it would be possible to define program-code. 'effectiveness' or 'efficiency' independently of the b. Effective (i.e. as little as possible) 'market' of system programmers. However, it is reaction-time of the program. becoming very clear that it is easy to build com­ c. Effective labour supply, if the reserve of puters but very difficult to educate and train man-power is pruned. persons capable of using these computers. Therefore, the 'effectiveness' problem can be treated exactly only if we define a relative refer­ ence value for all participants. This shall be the 3. Programming technique today 'sum of all costs' of a computer installation (hardware + software). Effectiveness in this Current developments or developments in the sense means the minimisation of total costs by immediate future are indicated by the following suitable combination of the hardware configuration typical signs: with a particular programming technique. a) Prices of core store A clear tendency to lower costs can be seen in 2. Historical development of programming technique this sector. This is a result of new production techniques (wire store, later on MOS store, in The first computers that appeared on the industrial the future holographic mass memories) which will market possessed so little core storage that pro­ bring much more saving. At present, we must grams could only be produced directly in machine assume prices of 0.15 to 0.20 DM per bit, but code (MC). The middle fifties saw the invention of between 1975 and 1978 we may expect 0.05 to symbolic programming with the Assembler Code 0.10 DM per bit for machines with a cycle time (e.g. in 1956 the language SOAP = Symbolic Opti­ under 1 µ.sec. By 1980 at the latest we may mal Assembly Programming at the IBM's 650). expect that the price for storage capacity will fall This new method of symbolic addressing was very by a further factor of 10 or more. Perhaps by convenient at the time. The significant sign was then we shall have the cheap Tera-Bit memory the 1: 1 - conversion between the assembler and for each computer (with 10 1 2 to 10 14 bit and a the machine code. For many years most people read/write cycle time of 20 nsec). believed that this conversion was the only method of producing optimal programs in the sense of b) Capacity of internal stores minimal code length. As a consequence of falling prices, the store The development of FORTRAN, enforced by capacity will generally increase (also for process IBM, was the beginning of a programming tech­ computers). A new method of addressing by the nique independent of the special features of a paging mechanism will be of great importance in particular machine. At the same time, the con­ this context. This method will enable the address­ cept of FORTRAN was made in such a way that an ing of very large data blocks in spite of small data effective MC could be generated out of the source units (e.g. 16-bit words). In the immediate future code. Same 'risky' features of high-level we will also have for process computers a maxi-

29 mum store capacity of 1 million words or more. b) Larger volume of data As a consequence of these facts, we can also Usually this is a result of more complex problems. produce core-store-resident programs by higher The higher level languages (especially ALGOL level languages. If a demand paging mechanism and PL/1) can bring about an important improve­ is available, one can renounce the overlay ment in data management. principle for large programs. c) Higher data-structures c) Programs on background stores Problems connected with the increasing use of We also believe that external stores will become interactive displays working with real-time com­ considerably cheaper than internal stores, and puter systems can only be overcome if we intro­ therefore we shall need a reasonable roll-out duce new data-types - the so-called 'structures' technique. Because of the greater capacity of and 'pointer-variables'. With these new elements these internal stores it is possible for greater we can solve the problem of referencing from one parts of the software belonging to this technique data-list to another connected with it. to be taken over by the operating system. There­ PL/1 (using the concept of 'pointers') and fore t-he application programmer will be ALGOL 68 (with the much more useful reference unburdened. As a consequence, in the future it concept) give very serviceable means to the pro­ will also be possible to producelarge program­ grammer. Programs for storage and treatment ming systems by means of higher level languages. of complicated pictures (by suitable data­ structures) can be prepared and tested much d) Use of high-level languages faster by these means. After the introduction of FORTRAN, a few further high-level languages (ALGOL, COBOL, PL/1) d) Coordination problems in real-time-program­ were developed. These languages can facilitate ming the work of the application programmer, especially An additional complication in real-time-program­ in mathematical (ALGOL) and economic (COBOL) ming is the (temporal) coordination of simultane­ problems. ously running programs. For this we have the Dijkstra-Semaphores, which allow coordination of single programs. 'Higher coordinating functions ', Many groups throughout the wor ld are working giving a real facilitation to the user, will be on the development of special real-time languages developed. In every case, the possibilities of (e.g. Process-FORTRAN, PEARL, LTPL). The coordination in a higher-level language give a newest and most modern of these languages pro­ formal simplification to the user. This can vide for very comfortable bit-, byte- and string­ increase the clarity of the problem and conse­ handling, and for definition of special data struc­ quently prevent the appearance of errors, tures. Therefore many of the tasks of the especially deadlocks, in programming. All this application programmers are considerably will contribute to a more effective programming reduced. In special cases, the time for the technique. development and testing of programs will be lowered by a factor ten. However, improvements due to revised pro­ gramming techniques will be nearly counter­ balanced by the increase in the complexity of new On the one hand we find, in general, consider­ tasks to be programmed. Nevertheless, very able facilitation of the programming technique, considerable progress has been made, as com­ but, on the other hand, there are many difficulties pared with programming techniques at the begin­ which arise from the increasing use of computers ning of computer development: we now have for solving more and more diverse problems. A excellent higher programming languages. With few of these problems are listed below: these we are able to solve very extensive tasks such as computer-aided design, numerical a) 'Mathematization' of the tasks weather-forecasting, complicated real-time pro­ Many interesting problems (e.g. weather­ cess control, and so on. forecasting by computer, computer-aided design, linear- and dynamic-programming) now involve greater mathematical effort. The same problems 4. Consequences arise from the urgency for mathematical treat­ ment of many problems in commercial and Maximum efficiency, in the sense of minimisation management information systems. Effective of total cost, can be reached for a given problem effort is possible only ü the highly specialized and given hardware installation only by careful men engaged in solving these problems are considerations of, on the one hand, higher pro­ economically employed and relieved of routine gramming effort and, on the other hand, larger tasks. For this, the use of higher level languages core store. Unfortunately, there are a number of is very important. basic obstacles which are not precisely measur-

30 able but could hinder the application of higher Therefore we neglect, for the moment, the level languages. dependence of vs on program length LA • 3. The written program shall run or be instal­ a) User prejudice against higher level languages led f times. Frequently, this follows from deficient knowledge, 4. We assume fixed software costs K5A in insufficient training and erroneous generalisation. assembler programming for given program Jn many cases, the very abstract and sophistica­ length ( Ksc is the value for higher level ted specification (here one thinks of the ALGOL 68 languages). report) will hinder the user, because he believes 5. In the same manner we assume fixed hard­ that this language is as difficult as the understand­ ware costs. For this we apply the price of ing of the language specification. The well-trained the additional core store in DM per word. system analyser does know that the contrary is 6. If we further consider the program dynami­ true, but the unskilled application programmer cally running, we see that the running time (and the number of these is much greater :) will can become longer by a factor v t· not use such a language. Therefore in this field 7. Finally, if the program runs in a computing of application, much explanation, clarification centre, we additionally have to consider and education must be done in the future. leasing cost for one word (ca. 0.0015 DM/hr) b) Alleged uselessness of higher level languages for solving real-time-problems leasing cost for central processor Unfortunately, objections of this kind are often unit (ca. 250 DM/hr), and justified. We must, however, think not only of +' existing means (e.g. supervisor calls in ' A absolute running time of the pro­ FORTRAN), but we must also take into considera­ gram (written in assembler code). tion that latest developments (e.g. PEARL and In a quantitative analysis we must compare the LTPL). When compilers are available, e.g. for savings of manpower costs, that is PEARL, and when the usefulness of this high­ level language is demonstrated for practical problems, the most conservative user will adapt himself to programming in higher level languages. with the increased hardware costs or leasing costs. Therefore, we have to consider two differ­ c) Hardware limitations ent cases: Core stores ,c>ill become cheaper, but their size cannot be raised as much as one would like (because of addressing problems). This is A. lncrease of hardware costs especially true for very small computers (e.g. computers for measurement instrumentation or If a vendor desires to sell a computer f times other special purposes); in these cases, the together with a special application program, he application of higher level languages cannot as must find the most economical solution for the yet be recommended. whole system. For this, the vendor could write the program in a compiler language (to save time) A greater part of these objections will have and pay himself for the (perhaps greater) addition­ lost its importance in the course of the next few al hardware cost. This additional cost is for f years. We will therefore neglect these objections applications of the same program: in the following quantitative considerations (especially the limitation on core stores). We can (2) then say that we are able to perform easier and faster programming for a given problem by using Here is a numerical example (for 24-bit word, a high-level language. We can thus introduce the 5 000 FW /NY): following assumptions for a program of length LA (made in Assembler language): KsA = 20 DM/FW 5 DM/FW 1. By using a higher level language we need = 3 f only a fraction 1/n of the time needed for n = 3. programming in assembler language Then from Eq. (1) (O < 1/n,;;;1, n real). 2. By the use of this high-level language the 20·(1 - 1/3) 13.34 object program is lengthened statically by and from Eq. (2) a factor vs > 1. In the case of very long programs, we can reach vs ,;;; 1, but this 3 ·(1.7 - l) •5 = 10.5. is only a theoretical limitation, because it is almost impossible to make very long Therefore, A5 is greater than A 8 and the use. of programs in assembler language at all. a compiler language (higher level language) is

31 more effective. We now get = 5 • 4 A M 50(2 · 10 2.5 · 10- (4 - 1) + 250 · ll 8. lncrease of leasing costs 50(50 • 3 + 250) When programs in higher level languages are to 50 · 400 be used in the closed shop of a computing centre, 20,000 DM the costs will be higher both statically (vs) and dynamically (vt) (as compared with assembler Now the additional leasing costs are high, but in programs). These higher level language pro­ this case everybody will use a compiler-language grams, therefore, will need more core-storage (just because of the length of the program!). (in units of leasing costs: Mxsn; •LA· (Vt · v 8 - 1)) Beyond that, the savings of software costs are, and more computing time (given by M •(V 1 . = 5 zE t - )) numerically (because LA 2 · 10 FW), The sum of these two effects must be multiplied by the absolute running time t and by the num­ A As = 2 700 000 DM ber of applications, f. Therefore, the increase in leasing costs is then given by t Summarizing: Only if A and/or f are large enough is it worth programming by assembler A ·t • M + M V 1 M � f A[LA KSPW (vt vs -l) ZE ( t - )] (3) language. Quantitatively, for this purpose with tA = 1 hr, the value of f should be 5,000 to The value of Mxsrn is very low. If we assume 10,000. KH = 5 DM/FW and 20,000 total working hours (time of amortization, about 5 years), we get -4 MKSPW = 2.5 · 10 DM/hr. · lt should be emphasized that, besides the economi­ cal reasons, there are many other points of view calling for the use of a compiler language, e .g.: Now consider two numerical examples: 1. · Much better form of documentation. 2. Saving of know-how when a new computer family with the same software package is (1) KSA = 20 DM/FW (see above) used. 3. Simple changeability of the program. L = 2,000 FW A For the user-programmer and the system n = 3 (therefore 1 -1 /n = 0.67). analyst: Then, from Eq.(1), 4. Faster programming and relieving of 3 routine tasks. A = 2 • 10 ' 20 • 0.67, s For the producer and vendor of the data process­ 27,000 DM ing system: 5. Relief of own software deliveries specific for certain application problems for the f = 20 customer, provided that excellent compilers t M -4 A = 12 min = 0.2 hr KSPW = 2.5 · 10 DM/hr · for an effective high-level language are V = 1.2 available. t For the immediate future, assembler pro­ 2 vs = 1.7 MzE = 2.5 · 10 DM/hr gramming will remain for only two major software Then, from Eq.(3), fields: On the one hand, for frequently used system A = 3 • -4 • + M 20' 0,2 [ 2 ' 10 2.5 • 10 (1.� • 1.7 - 1) programs, as the operating system itself and 2 the various compilers, and, on the other hand, + 2.5 · 10 • 0.2 l for frequently needed application programs 2 4 [ 0.5(2.04 - 1) + 0.5 · 10 ] which must have a very short code. One can 4(0.52 + 50) find this in interrupt programs with very short response times or in the field of very small "" 200 DM computers (e.g. computers for measurement instrumentation with a 'software modular sys­ tem'). In this example we can neglect the additional A leasing costs M (the first term is nearly zero). Final observations

(2) If we now increase LA to 200,000 FW, Effectiveness, that is, minimum cost of the whole vt = V8 to 2, tA to 1 hr, and f to 50, we reach installation, especially the installation of a pro­ a very unfavourable case. cess computer, can only be reached by careful

32 consideration of all cost components. For this, and the software designer of the language - have we will need more and more higher level enough openmindedness and understanding of the languages. But as assembler programming loses problems can we expect a solution of general its influence, we must develop more efficient satisfaction. higher level languages for real-time programming. This is a very wide field for computer scientists in industry and the various research centres for Discussion computer science. Extraordinary efforts will be needed for a break-through in this field. In spite C. I am sure the author of this paper does not of all the difficulties, we should attempt to reach feel he has the final answer on efficiency meas­ a world-wide standardization of such a language. ures, but I applaud attempts like this. They are But we must expect that the user-programmer better than none - you at least have something to will carefully examine these new language make individual judgements from - and also some­ features and really use such language if possible. thing to change and refine as your understanding Only if both sides - the application programmer improves.

33 Workshop on general considerations on real-time programming

Chairman: Prof. Dr R. LAUBER Stuttgart, W. Germany

The discussion included realistic assessments of K. TPLl at Essex has been used to program a the gains from using high-level languages, and stored program controlled telephone exchange. the overhead penalties they carry. The benefits lt had substantial overheads: 90% on space in of standardisation were overshadowed by the main store, and 35% on running time. lt has been practical difficulties of achieving it. studied fo find the reasons for the inefficiencies, and a second language TPL2 has been designed to remove them. This iteration of language design is very necessary but elapsed time must exist to Comparisons of high level and low level programming permit it.

S. We should recognise that even when the goal is H. CONTRAN has been used on a process control to program in a high-level language, some application (cement kilns) in England. Unfortuna­ fraction of the programming will be in low-level. tely, it introduced considerable overheads in In my experience (an operating system for an additional storage requirements and execution automated radar system), the proportion of high­ time. This suggests the question whether applica­ level to low-level programming is about 80: 20. tion demands still make it necessary to squeeze This is not simply to achieve efficiency - high­ the best performance possible from current hard­ level programs can be tuned up. A second look at ware. There still appears to be no spare power high-level programs often produces a highly or capacity in computers to tolerate the reduction efficient object code, although the initial version in efficiency introduced by a programming in a may have been poor. In one case the high-level high-level language. language version had 50% less code than the original assembly language version (perhaps because the compiler-writer himself coded it!). Standardisation

L. In a real-time data gathering system we found S. lt is desirable that we have a generally that 85% of the code could be written in Real-time accepted real-time language. However, this is FORTRAN, supported by an operating system unlikely to happen until it is promoted and written in assembler language. Coding in assembly supported by one or more large computer manu­ language may be necessary to reduce the size of a facturers. In addition it must not be too specific program. We had a 12 K FORTRAN program, of to a particular computer. What is needed is a which 2.5 K words were data, and converted it into virtual processor whose primitives are generally assembler. This brought the size down to 8 K agreed and can be realized on most hardware. still including the 2. 5K words of data, so indicates PL/1 is too close to SYSTEM/360. a reduction of code itself to 60% of the high-level version. D. ANSI committee X3Jl.4 is working on PL/1 Standardisation, and has admitted some important P. At the Royal Radar Establishment we principles: developed programs for a computer controlled 1. lt starts from the user's point of view, not radar in assembly language. Later when a compi­ the manufacturer's. ler became available the same problem was 2. You cannot standardise what is not reprogrammed in CORAL 66. The expansion in developed. code resulting from the use of high-level language 3. You must not neglect the Europeans.. was 20%. The total program length was l0K and less than 10% of this was written as code inserts Y. Is standardisation by ANSI more successful to optimise speed at critical points. than by a major manufacturer?

34 D. ANSI cooperate with ECMA, so it should be language for it: extended ALGOL is the helpful for both sides. lowest language that can be used. Because of the addressing structure which has to be y, There are plenty of languages all competing implemented, there are extra core memory for use. A sort of natural selection applies accesses, which make it a slower machine between them. than the equivalent 360. 2. The DEC system 10 (formerly the PDP-10) R. ALGOL 60 did not come into existence in this has two pairs of protection /relocation way. (base /limit) registers in addition to its index registers. This means that the code F. A standard language would gradually lead to a and data can be addressed using different standard operating system and then to a standard base registers, and so one can easily computer. This is not allowed! product re-entrant code. Making use of this facility, it is possible to produce a Y. CORAL 66 was defined by users, and has been real-time system in which the applications used for many applications, including an operating programs are re-entrant, even though system. written in COBOL!

P. CORAL 66 compilers are available on a num­ C. Concerning high-level languages and standard ber of machines in the UK now. These compilers software packages, both are needed in different conform to the definition of the language published circumstances. by the Stationery Office. They have been imple­ We should distinguish at least two stages of mented in some cases by the computer manufactur­ evolution: ing firm and in other cases by the RRE. The In stage 1, the engineer has just a rough idea compiler typically needs a simple machine with what the process control computer has to do, and 16 K of store. lt is planned in the future to allow he is experimenting to determine the appropriate modular extensions to the facilities of CORAL 66 algorithm. For this stage he needs a flexible so that where more space is available a more general-purpose high-level language. powerful compiler can be used. In stage 2, problems are well settled, and satisfactory algorithms known. Software packages containing these algorithms can be provided for General comments the user.

T. There is a converse effect of machine archi­ J. The level of language is not important if you tecture on programming languages. For example: have good people, but it is when your staff are not 1. The Burroughs B6700 is an ALGOL so good. They will meet deadlines, but the quality machine and there is no assembler of the programs cannot be guaranteed.

35

BASIC DESIGN PRINCIPLES OF OPERATING SYSTEMS

Chairman: Dr I. C. PYLE

37

Adaptive operating systems

H. WETTSTEIN Institut für Informatik, Universität Karlsruhe, W. Germany

1. lntroduction ting system.

In conventional data processing a great many computer users are disillusioned with the 2. Analogies in the area of control computers behaviour and performance of their equipment. Compilation times are too long, access routines The above-mentioned considerations led to a too slow and processors are idle most of the time. certain conclusion following an economic reason­ Frustration has spread because "computers are ing. However, within the area of control compu­ not living up to their potential" [1]. lt has, for ters we come to a similar conclusion from a dif­ example, come to the author's attention that in ferent point of view. Control equipment is usually computing centres the policy is sometimes sold in far less quantity than conventional pro­ adopted not to use more than one work file in a cessing equipment. In contrast, however, control data processing program. If the logical structure equipment shows at least three additional limita­ of a problem is such that more than one sequen­ tions: tially organized working area is needed, the 1. lt is usually resource-bounded, which recommendation is propagated to open a directly means that efficiency in software plays a accessed file and to partition it into several much bigger röle than anywhere else. sequentially organized subareas, the access 2. Performance with respect to switching mechanisms in this case being established by the times between processing or availability programmer himself. This approach obviously rates is a very important factor. involves a repetition of efforts already being 3. The operating environment varies greatly invested in the implementation of the operating from one installation to another, but is system itself. The reason for this is the constant within the same installation. apparent slowness of the operation of several These restraints make it a necessity that almost sequential files concurrently. every installation be equipped with its own specific lt is the author's opinion that such and similar operating system. Under those circumstances it weaknesses of operating systems is due to the is a matter of survival to produce the individual fact that those systems generally comprise far systems by automatic adaptation. more capabilities than an individual installation really needs. Operating systems are intended to serve a great, and especially a heterogeneous, 3. Previous approach community. Therefore, it has been the manu­ facturers' policy to incorporate as many features Of course, the idea of individual adaptation is not as possible in order to increase the probability new. There are several examples of systems that the needs of an eventual customer can be where the possib lity exists of selecting predeter­ fulfilled with the existing product. This is an mined components from a collection of modules acceptable policy from the manufacturers' point kept in a library. Such selection procedures have of view; it is drastically inefficient from the successfully been used to incorporate for customer's point of view. instance: What can we do to overcome this conflict? An 1. The drivers for specific 1/0-equipment. obvious solution, satisfying at least the user, 2. Transition areas, work space, etc. would be to implement an operating system for 3. Certain macro functions. every single environment. Of course, this 4. Or even certain language processors. conclusion can only be followed if the fabrication A selection process is usually called 'system of an operating system can take place automati­ generation' and is generally executed when a new cally. What is therefore needed is a kind of installation has been built up or when a configura­ master or primary system including all possible 'tion has changed. The system generator needs as features and capabilities from which special an input a description of the configuration and a systems can be deduced and adapted to the list of certain wishes. Sometimes the possible requirements of individual installations. Such a alternatives are all drawn on an order sheet as a master system we like to call an adaptive opera- flow diagram and the customer has to mark a

39 the following strategy 1. Design an operating system as general as possible. 2. Incorporate as many features you can think Peripheral Peripheral Peripheral of in all degrees of freedom. Typ A Typ B Typ C attached attached attached 3. Take the necessary precautions for reduction of the generic components to their simplest versions.

5. Formulation

Inclusion of Inclusion of Having recognized that our aim is not a component capability X capability Y adaptation, it is clear that a system cannot be generated by binding together selected members from an object module library. We can imagine that differences between variations of components or references to other, possibly missing, compo­ nents will very often show up only within short instruction sequences. Therefore, the object module is not the proper unit to keep an element of an adaptive operating system. What is needed is an implementation level where address refer­ ences have not yet been resolved or, in other Inclusion of capabil ity Z words, are still in symbolic form. Such a level is some form of programming language, in this case, preferably a speciat-purpose language for '------,----__.path of selected components system implementation similar to PL 360 [2]. However, this higher-level language approach Fig.1 Selection of components for a system generation solves only one side of the affair. Nothing has yet been said about the composition or selection procedure itself. Again, the problem is how to know whether a certain sequence of statements single path through the various blocks (Fig. 1). should be incorporated in a target system or not. By this means, selection of mutually exclusive Obviously, a description from the outside via components can easily be avoided. A good control statements is not feasible. Therefore, example of this philosophy is the system ordering the relevant parts must themselves bear appro­ and generation procedure of the SIEMENS 300 priate markings which tell the generating process series. In contrast to what follows, we will call the conditions for incorporation. Since those this kind of modification component adaptation. conditions may be very complex, it is apparently helpful to use again the means of a higher-level language. For instance, the conditional incorpora­ 4. New approach tion of a could be described by a sentence like Component adaptation cannot comply with the strict demands for optimality. Surely it is pos­ IF ( conditions> THEN ( piece of program) • sible to exclude parts not needed in a system? Later, it will be seen that the repeated incorpora­ But, nevertheless, the basic structure, the tion of program pieces, possibly slightly but ground philosophy of the systems, remains the systematically changing from repetition to repeti­ same. If, for instance, a system is designed to tion, is also very useful. This can be expressed manage n processes concurrently, it is not an as easy task to modify it for the management of n + 1 FOR DO ( slightly processes. Or, if a system manages a certain changing piece of program) list dynamically with capabilities for insertions and deletions, it is impossible to simplify this The and part to a static handling when the operating in the examples above contain variables which environment is definitely fixed. However, only actually control the composition mechanism. modifications of this kind justify calling a master They can be manipulated. Especially by assigning system a really flexible and powerful tool. values from outside (via READ-statements), the Especially timing factors can effectively be influ­ entire composition process is under external enced. We like to call this mechanism a control. We finally see that all the approved structural adaptation. From there, we propagate language constructs can successfully be applied

40 to describe the composition scheme. Thus the This, indeed, reads much more smoothly because composition scheme becomes itself a program, the delimiter ATTACH can be considered as a which, last but not least, can be executed. In standard procedure call with fact, this execution represents the act of as a parameter and with the function of outputting composing a target system. If the composition its parameter string. This is exactly our inter­ process is fairly complex, one can imagine the pretation mentioned above. amount of variability among the target systems. In order not to make a language decision at Nevertheless, the composition process can be this moment, we have chosen in the following kept machine-independent to a reasonably high examples to accentuate the composition parts by degree. underlining.

6. Composition compiler 7 Examples

What do we really mean by 'execution of the The following two examples may be considered as composition program'? Obviously, the < pieces two tiny cut-outs of a hopefully adaptive system. of program> in the examples above are not Suppose we want to reserve space for a varying intended to be executed because they constitute a number of process control blocks (PCB), but only part of the target system. We must adopt a new in the case when the processing environment is kind of interpretation of a statement's meaning as predetermined, that is when the list of the PCB follows. In scanning the program text from left is static. Each PCB consists of the following to right and obeying the rules laid down by this components (fields): program, every time we come across a string of characters that do not belang to the composition Contents Data Type scheme we attach them to an output stream. When - continuation address (CNTADR) ADR the execution of the composition program comes - ready indicator BIT to an end its output stream forms the generated target system. - activation indicator BIT Of course, the consist (only if activation should take of phrases similar to the composition language. place individually) This raises the problem of distinguishing between - safe area for arithmetic two linguistic levels. register (REG) WORD Musstopf [3] has recently discussed this

Of course, if the fraction of composition elements RDYIND BIT in the over-all picture prevails, it is easier to IF ACT = 'INDIVIDUAL' THEN , switch states at the beginning and end of normal ACTIND BIT,i passages, e.g. IF INTRPT = 'YES' THEN , REG WORD; ); ; IF B THEN ATTACH ((piece of program)); END;

41 lf it happens Fhat PRLIST = 'STATIC' , 8. Further problems INTRPT = 'NO', ACT = 'INDIVIDUAL', and N = 3, then the output of the above composition Besides giving the impression of the formulation program would be: picture, the last example demonstrates the question of resolution of data structures. The DECLARE PCB1 (CNTADR ADR , RDYIND BIT , ACTIND BIT); composition scheme contains a statement for DECLARE PCB2 (CNTADR ADR , RDYIND BIT , ACTIND BIT); stepping on a list pointer, the stepping function DECLARE PCB3 (CNTADR ADR , RDYIND BIT , ACTIND BIT); being dependent upon the list structure. Since the allowance for various data structures will prob­ ably constitute a major part of an adaptive operat­ This example confirms also the former assump­ ing system, one can imagine the numerous places tion that the fraction of composition text could where similar primitive operations will occur. outweigh the normal text. Structure-dependent differentiation, however, The next example shows the construction of a should not appear as a dominant part of the simple scheduler. Starting from a current ele­ procedural division of the operating system. lt ment of the PCB-list pointed to by a pointer P will therefore be necessary to make available the scheduler is intended to search cyclically for list-handling operators like 'step', 'insert', the next process ready for execution. lt should 'attach', 'delete', etc., being defined for any of be adaptable to the structure and contents of the the relevant data structures. The resolution of PCB-list, the latter being assumed to be either a these operators would be deferred until the final dense list or a cyclically linked list with a pointer translation phase. to the successor element in a field PCB.PTR of each element. The scheduler could read as follows: 1. MORTON, K.W., 'What the software engineer can do for the computer user ', Advanced Course on Software Engi­ neering, Munich (1972). NEXTPROCESS: 2. WIRTH, N.1. 'PL 360, a programming language for the IF PRLIST = 'STATIC' THEN BEGIN P : = P+1; 360 computers', J:ourn. ACM, Vl5, pp. 37-74 (1968). 3. MUSSTOPF, G., 'Sprachgesteuerte Modifikation von IF P = N THEN Quell-programmen', Zweite Fachtagung über Program­ miersprachen der Gesellschaft für Informatik, Bericht p : = 11l; Nr. 4 (1972). END ELSE P PCB.PTR [P]; ;_

IF PCB.RDYIND [P] = l1l Discussion IF ACT = "INDIVIDUAL" THEN OR PCB.ACTIND = 0; Q. This proposal seems to be an extension of the IF INTRPT = 'YES' THEN REGISTER : = PCB.REG [P]; , conditional assembly feature used for example in GOTO PCB.CNTADR [P]; the PDP 10. The big problem is in debugging the resulting operating system. This can be very Given the same situation as before the composi­ expensive, and in practice is not always done. tion run generates The result is that when one generates a 'tailored' system it does not work. Might this apply to your method? NEXTPROCESS: P : = P + 1; IF P = 3 THEN P : = �; A. I am not particularly interested in the two IF PCB.RDYIND[P]=l1l OR PCB.ACTIND=l1l THEN language levels concerned, but in the security of GOTO NEXTPROCESS; the system components which this method encourages. The structure of the system gives GOTO PCB.CNTADR [P]; built-in reliability.

42 Description of operating systems in terms of a virtual machine

H-P. ROST Al/gemeine Elektricitäts-Gese/lschaft, AEG-Telefunken, W. Germany

After the impetuous course of compiler develop­ function, but also the quantitative exigency. The ment in the first and second generation, after latter is not true for technical-scientific or com­ many roundabout ways of proving outstanding mercial computer systems, because not all the technological methods, the third generation was programs to be executed are known from the first. apparently successful in consolidating the pro­ But in the greater part of the process computer cedures and by this the terms of computer know­ installations the situation is better. Here the ledge. Well defined slogans were introduced to structure of the program system is given by the release unbiased information. Everybody knows technology of the plant and will not change for a today the meaning of multi-address instructions, long time. In our example the user of a process byte-string manipulation, decimal arithmetic, computer knows whether his problems need a context and index registers. With great effort, great amount of floating-point arithmetic or not. these terms and their usage were standardized on These thoughts lead us to the following state­ an international basis. The possibility of descrip­ ment. A computer system behaves like a central tion and comparison of digital computer systems processor which is able to execute certain func­ seems to be based on their so well-defined data. tions. The addition of software to a physical But that is a delusion. The understanding ends central processor manifests itself like using an at the border of the physical device. This means imagined central processor unit with extended that only the comparison of physical devices is functions. This imagined central processor unit possible. But is what the manufacturer develops I call a virtual computer. Its features can be and what the user buys only a central processor? defined and described in hardware terms. A central processor unit without standard software This interpretation of terms seems particularly is saleable only with mini-computers. At the serious if the physical description alone would same time, the meaning of standard software and give a false impression. Examples of this are the description of it is far from standardized. often found in descriptions of interrupt units. The Even an agreement as to the functions an Operating interrupt unit often consists of modules for the system has to fulfil is not firmly settled. collection of events, which generate an interrupt From the user's viewpoint it is irrelevant for the module as a whole and prepare a status whether a function he needs is realized in hardware word identifying the source of the interrupt. The or in software, provided that it solves his problem reaction time for the representative interrupt quantitatively. I shall discuss this matter by (shown in the design paper on the physical central taking floating-point arithmetic as an example. processor) is unimportant as long as the time The following solutions are possible: necessary to read in and interpret the status word is unknown. The latter is done by a program, the Hardware processor so-called interrupt handler. But its consumption Micro programmed processor of time is not shown in the normal data sheets of Interpretation of non-defined operations code a computer. For a virtual computer the behaviour Assembler-generated built-in-macro of the interrupt unit can be described in the follow­ Assembler-generated library procedure. ing way: Each solution owns by equal quality a different For each interrupt input it is definable whether working speed and need of working memory; it works on a channel with low or high speed. there are differences in quantity. The system The performance of the channel consists in (hardware and software) is in all these cases able identifying the interrupt input, interrupting the to use floating-point arithmetic, although the running program and starting a code routine physical central processor in some cases is attached to the interrupt input. Each interrupt inefficient to do so. is followed by a time interval in which other Naturally this train of thoughts is meaningful interrupts are only marked down. These are only in the case where the user is able to perceive not served in the order of input sequence, but not only the qualitative requirement of a computer in a fixed priority order. 43 In most cases, the above code routines handle parameters coupled with every I/0 action by peripheral devices and are called drivers. storing them in itself. In hardware terms, the Usually peripheral devices are coupled with the control parameters are transferred to the I/0 central processor by a hierarchy of hardware processor of the specified channel. This means units named data channel, channel multiplexor or that the source program is with this action ready device controller. The physical description of for working again. This has great influence on these hardware units shows whether the device the design of program systems for stochastic pro­ will work in character or block mode, whether cesses, where noone is able to predict the next data or command chaining is allowed, whether program start. control operations are realized by special com­ It will be clear that this device-independence mands or control characters. of I/0 commands is a strong tool for testing pro­ lf the driver is planned to output a new charac­ grams, structuring program systems and widen­ ter after each interrupt, to interpret certain con­ ing the field of application by changing devices trol characters by special actions, the device without modifying the programs. works for a user behind the intersection line of The virtual devices of the virtual processor the driver equivalent to a device with a very work off some multiplexors: the peripheral comfortable controller. This being part of the devices on the I/0 multiplexor, the background manufacturer's standard software, the user is not memories on the memory multiplexor and the in a position to differentiate between hardware programs on a (virtual) multiplexor of the arith­ and software solutions. metic and control unit. The last works in so­ In the virtual description, this situation is called burst mode overlayed by a priority strategy. stated by the fact that all peripheral devices are (This is the sufficient hardware description of a operated by the same I/0 programs. Following multiprogramming operating system.) this outline, the virtual computer will translate A virtual computer for the control of a stochas­ between external and internal codes and bridge tic processor should have the facility of command the difference between the relatively slow peri­ chaining of I/0 operations for all devices. pheral devices and the central processor by Interpreting this for the programs, we speak of external buffering. The question is: where is parameter buffering for many calls of one pro­ this procedure to be terminated? gram without confusing the order of sequence. I have shown that all required functions not In this description, no special position is held realized in the physical central processor are for the interrupts. In the virtual computer, inter­ attainable by software imbedded in the standard rupts terminate in calls for programs, undistin­ operating system. On the other hand, all functions guishable syntactically, but only semantically generated by supplemental software are describ­ from calls from other programs. Therefore it is able in terms of a virtual computer. The advanced clear that all interrupts can be simulated in test standardization in the hardware field shows that it or in case of failure by certain programs. is now preferable to describe structures and attri­ The AU multiplexor not only switches from one butes of operating systems in this way. program to another, but also switches the sur­ Let us now try such a description for a central roundings of the program. This means that every processor with a basic monitor including an I/0 device is able to communicate with other devices system as an example. (These undefined terms only by means of the virtual I/0 statements. For show that no two people will agree on their usage, every program-type device therefore it seems and defining them would lead to other undefined like being the only program on an own central terms, and so on.) processor in an environment of devices, some of In the example, the virtual central processor them also being programs. serves a great number of devices connected with This feature of the virtual computer means it, some being peripherals like teletype or tape resource allocation strategies, a swapping mecha­ punch, some process-elements like drgital output nism and virtual addressing. or analogue input, some background memories, The above account should give some idea of the serial like magnetic tape or random like drum hardware description of a virtual processor. and disc, and most being programs. For the pro­ Once the qualitative aspects are clarified, it will grams running in this virtual processor all these be an easy task to give quantitative answers in the devices act equally. This means that they are same manner. It seems that this method of started with the same virtual I/0 commands. description, definition and comparison of different This feature is very valuable in industrial process process computer systems is much easier than systems because you can replace, in certain the definition in special software terms. Last periods of time, one peripheral by another, by a but not least, with new developments, such as bulk memory or by another program. Structuring micro-programming on the one hand, and mult­ and restructuring of the program system will be minis on the other, the hardware borders have made easy by this. become so soft that only unified descriptions of When executing the 1/0 command this virtual systems as a whole, including the above concept processor unburdens the source program of the of the virtual computer, are able to provide a

44 base for standardization and comparison. devices?

A. For every device including non-standard ones Discussion the dri ver has to implement the appropriate virtual 1/0 statements. Q. How do you deal with drivers for non-standard

45 Interrupt handling in real-time control systems

R. BAUMANN Technica/ University of Munich, W. Germany

lntroduction interrupt handling facilities distinguish real-time control systems from other third generation Typical Third Generation Computing Systems are computing systems. A typical component of a time sharing systems, teleprocessing systems, real-time control system is one that is dedicated information and service systems, interactive to handling external interrupt signals. Neverthe­ systems and computer networks, as well as real­ less, for practical reasons, external interrupt time control systems. They are designed to pro­ handling is usually embedded in general interrupt vide the user with a wide range of problem­ handling facilities. solving facilities on a low-cost basis through Following this guideline, a working group of sharing resources and information. The program­ Unterausschuss 'Programmierung' of VDE /VDI mer especially wants to find an efficient software Fachausschuss 'Prozessrechner zum Messen, environment for development, debugging and Steuern, Regeln' began to describe hardware and execution of his programs. software features of an interrupt input dev_j.ce Owing to the complexity of these systems, (Appendix). This effort can also be considered general software must be designed very carefully, as preparatory work for future standardisation following sound engineering principles similar to within the scope of Arbeitskreis C of Fachnormen­ those of hardware design. The structure of the ausschuss Informationsverarbeitung (FNI) im systems considered is determined primarily by Deutschen Normenausschuss (DNA). functional components independently of the realisation which can actually be given either by hardware or software units. 1. Classification of interrupts Since properties like concurrency of programs, automatic resource allocation, sharing of Owing to their urgency, interrupts can be classi­ resources, multi-programming, multi-tasking fied according to their origin as follows: and multi-processing are common to third genera­ 1. Emergencies (e.g. power supply failure). tion computing systems, general software for 2. Traps (e.g. every kind of error occurring these systems will also have much in common. in the central processing unit). We may therefore ask for components typical of 3. Peripheral interrupts (messages from real-time control systems only, which will not be peripheral devices). present in other computing systems. 4. External interrupts (messages from out­ A real-time control system is determined by side). its ability to synchronise with a technical process. Emergency interrupts are always served lt must therefore contain facilities to: instantly in order to save as much information as 1. Accept data from, and deliver data to, the possible in case of a breakdown. Traps should technical process at given real-time inter­ be checked before any other interrupt is served vals. (except for emergencies) in order to ensure 2. Act immediately in response to foreseen correct functioning of the computing system itself. or unforeseen events in the technical pro­ Hence interrupts of class (1) and (2) may have cess. immediate access to the central processing unit, From the point of view of the computing system, while those of class (3) and (4) are handled by a this implies that there must be a functional unit, distinct interrupt device. These should only com­ which can (at least temporarily) interrupt pro­ pete with other activities of the computing system cessor activities and alter the programmed on the same level of urgency. sequence of processes due to external events. Emphasis is on the adjective 'external', since interrupts caused by internal events occur in 2. Interrupt device every computing system which realises concur­ rency of programs, sharing of resources or even 2.1 The interrupt device has to perform the fol­ some modest fail-soft mechanism. lowing functions: We therefore conclude that mainly external a. Accept the interrupt signals. 46 b. Attach and evaluate interrupt priorities. request of highest priority for execution. c. Assign start addresses of interrupt response programs. Interrupt signals enter the interrupt device by 3. Interrupt execution interrupt entries, which can consist of three flip­ flops, the outer mask element, the interrupt 3.1 The interrupt is actually effected ü the fol­ location (holding the signal) and the inner mask lowing conditions are fulfilled on the processor element (see Fig. 1, Appendix). side: a. The state of main scheduling or supervisory program controlling the processor's activity 2.2 The set of interrupt entries canbe structured must permit the interrupt (e.g. according to in different ways by forming subsets according to a comparison between processor priority common properties such as: and interrupt priority). a. Equal interrupt priority. b. The piece of program occupying the pro­ b. Common mask elements (groupwise lock­ cessor must be in an interruptible state. ing). c. The instruction the processor is working on c. Common read /write instructions for the must be interruptible. mask elements. In multi-processor systems, interrupt requests d. Common response program. can be dispatched to all equal processors on the The subsets defined in this way are usually called basis of a comparison between highest interrupt groups, except for the case of equal interrupt priority and lowest processor priority. Such a priority, where the term 'level' is used. Obvious­ schedule makes the system more flexible than ly düferent structures can be realised simultane­ dedicating a single processor to interrupt ously in a given interrupt device (Figs 3 and 4, handling. Appendix). An interrupt entry can be: a. Armed or disarmed by setting the outer mask element. 3.2 In the case of normal competition [ interrupts b. Enabled or disabled by setting the inner belonging to class (3) or (4), see Section 1], it is mask element. desirable that the interrupted program can later These functions can also be performed groupwise. re-enter the processor without avoidable loss of time and information. This implies that, before releasing the processor, the contents of all 2. 3 Since it must be assumed that, in reality, registers and other locations relevant for continu­ several interrupt signals will compete for execu­ ation are saved by putting them in store or by tion simultaneously, an interrupt priority scheme just switching to another register block. is needed to determine the order of execution. Admittedly, in the latter case, the processor has When the decision as to whether or not to inter­ to provide for as many register blocks as differ­ rupt the processor's activity is to be influenced ent programs are to be served simultaneously by by the priority scheme, priorities are to be it. attached not only to interrupt entries but also to In several process control systems there is a the central processor, according to the piece of one-to-one correspondence of interrupt levels to program occupying it. In that case the priority register blocks. In other systems the register scheme is much stronger, since not only the blocks are scheduled by the supervisory program. single selection of an interrupt request, but also the interruptibility of the affiliated response pro­ gram is within its scope. Here is the chance to weld together external interrupt handling with 4. Characteristic time intervals other activities of the computing system, combining the priority-allocation scheme for In order to judge the capacitance of a real-time internal system activities and external interrupt control system and to compare the efficiency of handling. its performance, the user and the programmer Concerning interrupt priority we have to differ­ need information on time spans consumed in entiate between: interrupt handling. For reasons of correct a. Fixed priority (attached to every interrupt comparison, time intervals and related activities entry or interrupt level by hardware). should be defined clear ly. b. Variable priority (attached by software). When tracing an interrupt request from the c. Subpriority (due to a fixed sequence of origin of the interrupt signal to the completion of serving interrupt entries of a given inter­ the responding action, the following instants are rupt level). of interest (Fig. 5, Appendix): The interrupt device has to put in order the inter­ rupt signals standing at enabled entries, according PO - the interrupt signal enters the interrupt to their priority, and has to offer the interrupt device,

47 P1 - the interrupt request is announced to the 3. Zustandsbezeichnungen von Unterbrechungs­ processor, gängen P2 - the interrupt request is accepted by the 4. Unterbrechungsgruppen processor for execution, 5 . Auswertung der Priorität der Unter­ P3 - the processor starts to execute the first brechungssignale instruction of the specific response pro­ 6. Definition charakteristischer Zeitintervalle gram, P 4 - the processor finishes the last instruction ausgearbeitet von der Arbeitsgruppe "Interrupt­ of the specific response program, werke" des Unterausschusses "Programmier­ P5 - the processor starts to execute the first technik" des VDI /VDE-Ausschusses "Prozess­ instruction of the next scheduled program. rechner zum Messen, Steuern, Regeln". ·

For the intervals Ti defined by Mitarbeiter:

Ti = time between Pi-1 and Pi Prof. Dr R. Baumann, Mathematisches Institut der Technischen Universität München the following denotations are recommended: Dipl- Phys. J. Brandes, Institut fürInformatik, Universität Karlsruhe T1 - transition time Dr G. Heller, BASF Ludwigshafen T 2 - latency time Dipl-Ing. G. Hepke, IDT der GfK Karlsruhe T3 - recognition time Dr P. Höhne, Siemens ZL Munchen T4 - execution time Dipl- Phys. E. Huber, MBB Ottobrunn T5 - return time. Dr M. Prasser, AEG- Telefunken Konstanz Dipl- Phys. W. Rüb, Mathematisches Institut der Additional recommendations are: Technischen Universität Mün chen.

Tl + T2 - waiting time 1. Übersicht Tl + T2 + T3 - reaction time T3 + T4 + T5 - interrupt time Die Verarbeitung von Unterbrechungssignalen in einem Rechnersystem wird durch eine Unter­ T + + + 1 T2 T3 T4 - response time brechungseinheit veranlasst. T3 + T5 - organisational time . Der Unterbrechungseinheit fallen dabei folgende Hauptfunktionen zu: lt must be admitted that a considerable amount of 1. Annahme der Unterbrechungssignale philosophy is hidden behind these denotations. 2. Zuordnung und Auswertung der Unter­ Nevertheless, they may be helpful for comparing brechungspriorität, und the interrupt handling facilities of different real­ 3. Zuordnung von Anfangsadressen der time control systems. Antwortprogramme. Dabei bleibt offen, ob die einzelnen Funktionen ganz oder teilweise durch Hardware oder Software Conclusion realisiert sind. Es wird davon ausgegangen, dass die Unter­ Real-time control systems can be expected to brechnungsanforderung durch ein binäre Unter­ provide for interru pt handling facilities on differ­ brechungssignal gestellt wird. Die Übertragung ent stages. Hard interrupts will have immediate zusätzlicher Information über die Unterbrechungs­ processor access while soft interrupt requests ursache auf anderen Datenwegen wird hier nicht are handled via the operating system, competing betrachtet. with other activities on a priority basis. Zur Beurteilung,d es Verhaltens von Rechner­ systemen bei Unterbrechungsanforderungen muss auch der zeitliche Ablauf bei der Bearbeitung angegeben werden . APPENDIX

Editors note: This appendix has not been translated since it 2. Unterbrechungseingänge is concerned with precise terminology. Ein Unterbrechungseinganghat die Aufgabe, ein Entwurf für eine einheitliche Beschreibung von Unterbrechungs­ ankommendes Unterbrechungssignal wahrzuneh­ vorgängen men, zu speichern und gegebenenfalls gegenüber dem Rechner abzusperren. 1. Ubersicht Ein Unterbrechungseingang kann aus Aussen­ 2. Unterbrechungseingänge maskenelement, Eingangsspeicherelement sowie

48 --

Innenmaskenelement bestehen (s. Bild 1). Jedes 3. Zustandsbezeichnungen von Unterbrechungseingängen dieser Elemente kann den Wert L oder 0 speichern. Für die Zustände der Elemente eines Unter­ brechungseingangs werden folgende Bezeichnungen s vorgeschlagen:

TABLE 1

Bezeichnung

aussensperrend Aussenmaskenelement nicht aussensperrend

innensperrend Innenmaskenelement nicht innensperrend

Eingangspeicher- gesetzt element nicht gesetzt

TABLE 2

Zustand des Eingangs- Innenmasken- Aussenmasken- Unter brechungs- speicherelement element element eingangs

aussensperrend * * aussengesperrt

* * innensperrend innengesperrt u nicht nicht Abkürzungen: * bereit AME Aussenm-sken-Element aussensperrend gesetzt ESE Eingangsspeicher-Element !ME Innenmasken-Element * * s,u Unterbrechungs-Signale gesetzt belegt Vl Verknüpfungsglied l V2 Verknüpfungsglied 2 *bedeutet eine beliebige Besetzung des betreffenden Elements

Bild 1 Unterbrechungseingang

Aussenmaskenelement und Eingangsspeicher­ Daruber hinaus werden für die 8 verschiedenen element sowie Eingangsspeicherelement und Besetzungsmöglichkeiten eines Unterbrechungs­ Innenmaskenelement sind je durch ein eingangs 4 Zustandsbezeichnungen angegeben. Verknüpfungsglied verbunden. Bei geeigneter Alle weiteren Zustände lassen sich als Kombina­ Besetzung des Aussenmaskenelements verhindert tion dieser Bezeichnungen beschreiben. das Verknüpfungsglied Vl den Durchgang eines ankommenden Signals zum Eingangsspeicher­ element, bei geeigneter Besetzung des Innen­ 4. Unterbrechungsgruppen maskenelements verhindert das Verknüpfungsglied V2 die Weitergabe des im Eingangsspeicher­ Eine Unterbrechungsgruppe ist ein Satz von Unter­ element angekommenen Signals. brechungseingängen, die nach einer gemeinsamen Aussenmasken- und Innenmaskenelement wer­ Eigenschaft zusammengefasst sind. Solche den nur vom Rechner (DIN 44300) her gesetzt und Eigenschaften konnen z.B. sein: gelöscht. Das Eingangsspeicherelement kann von einer externen Signalquelle (bei geeigneter a) Gleiche Unterbrechungspriorität der Eingänge Besetzung des Aussenmaskenelements) oder vom Rechner her gesetzt, jedoch im allgemeinen nur Jedem Unterbrechungseingang ist eine Unter­ vom Rechner her gelöscht werden. brechungspriorität p zugeordnet (vergleiche 5). 49 s a) Schaltung: ;------i------, 1 ' UE 1 1 UE11

von AS

UE21

von IS

1 1 UEnl L _____ J ______J u nach V3

b) Schaltsymbol : Abkürzungen: AS Aussensperre IS Innensperre UE Unterbrechungs-Eingang V3 Verknüpfungsglied 3 (für Eingänge gleicher Unterbrechungspriorität)

Bild 3 Beispiel zur Gruppierung der Unterbrechungseingänge, bei dem Abkürzungen: Unterbrechungsebenen und Gruppen mit gemeinsamer Aussen- und AME Aussenmasken-Element 1 nnensperre zusammenfallen AS gruppenweise Aussensperre ESE Eingangsspeicher-Element JME Innenmasken-Element IS gruppenweise Innensperre s,u Unterbrechungs-Signale b) Gemeinsame Lese- und Schreibbefehle UE Unterbrechungs-Eingang Vl VerknÜpfungsglied l V2 VerknUpfungsglied 2 Bei einer solchen Gruppe können sämtliche V3 Verknüpfungsglied 3 Aussen-, Innenmasken- sowie Eingangs­ speicherelemente gemeinsam gelesen und Bild 2 Element einer Unterbrechungsgruppe beschrieben werden. Die Zusammenfassung der Aussen- bzw. Innenmaskenelemente dieser Gruppe heisst Aussenmaske bzw. Innenmaske.

Die Unterbrechungsprioritäten regeln den Vor­ c) Gemeinsames Sperrelement der Eingänge rang der Unterbrechungseingänge. Die Bearbeitung einer Unter brechungs-Anforderung Diese Gruppe besitzt ein gemeinsames der Priorität p kann nicht durch eine Sperrelement, das die Werte L oder 0 Unter brechungs-Anforderung gleicher oder speichern kann. Dieses Element heisst niedrigerer Priorität unterbrochen werden. Aussensperre, wenn es bei geeigneter Besetz­ Die Unterbrechungsgruppe mit Eingängen ung für alle Eingänge der Gruppe aussen­ gleicher Priorität p heisst Unterbrechungsebene. sperrende Wirkung hat. Es heisst Innensperre, Innerhalb einer Unterbrechungsebene wird die wenn es innensperrende Wirkung besitzt. Auswahl der zu bearbeitenden Anforderung Aussen- und Innensperre konnen vom Rechner durch eine Subpriorität festgelegt. her gelesen, gesetzt und gelöscht werden.

50 Abkürzungen: AS Aussensperre IS Innensperre UE Unterbrechungs-Eingang V3 Verknüpfungsglied 3 (für Eingänge gleicher Unterbrechungspriorität)

Bild 4 Beispiel zur Gruppierung der unterbrechungseingänge bei dem Unterbrechungsebenen und Gruppen mit gemeinsamer Aussen- und Innensperre nicht zusammenfallen

d) Gemeinsame Anfangsadresse des Unterbrech­ Priorität, die einer Unterbrechungsebene statisch ungsanwortprogramms oder dynamisch zu einem bestimmten Zeitpunkt zugeordnet ist. Allen Unterbrechungseingängen dieser Gruppe Die Prozessorpriorität wird einem Prozessor ist die gleiche Anfangsadresse des Antwortpro­ entsprechend der gerade von ihm bearbeiteten gramms im Rechner zugeordnet. Aufgabe zugeordnet. Die Prioritätsauswertung umfasst folgende Die Gruppierung der Unterbrechungseingänge Funktionen: nach den in a) - d) genannten Eigenschaften kann a) Zuordnung der Unterbrechungspriorität zu zu verschiedenen Strukturen führen. Bild 3 zeigt den aktivierten Unterbrechungsebenen. ein Beispiel, bei dem die Gruppierung nach b) Ermittlung der Ebene mit höchster gleicher Unterbrechungspriorität mit der Priorität. Gruppierung nach gemeinsamer Aussen- und c) Vergleich zwischen Prozessor-Priorität Innensperre zusammenfällt; im Beispiel des und höchster Unterbrechungs-Priorität (bei Bildes 4 fallen diese Gruppierungen dagegen nicht Mehrprozessor-Systemen Auswahl eines zusammen (das in Bild 3 und 4 verwendete Schalt­ geeigneten Prozessors). symbol UE ist in Bild 2 erläutert). d) Entscheidung Über eine Unterbrechung auf Grund folgender Kriterien: a) Vergleich nach c). 5. Auswertung der Priorität der Unterbrechungssignale ß) Generelle Unterbrechungssperre gesetzt? Es wird unterschieden zwischen Unterbrechungs­ -y) Vorliegen einer unterbrechbaren Stelle priorität und Prozessor-priorität. im Prozessor. Die Unterbrechungspriorität ist diejenige e) Innerhalb der Ebene mit höchster Unter-

51 t e e e e S l t e Un erbr chbar Ausführung d s rs­ e e igna komm im Unterbr chungs- 1 1 Stelle P te e e l e l e e P e . End d s Unterbre- e d. rogramms n B f h s d s t _ Erster B feh des Einqangsp ich r wunsch zur roc ssor e e e e t chungs - An wort I te P e el t Wahrn hmung d s sp zifisch n An ­ n rogramms an g m de S l t programms I nächs 1 1 igna s wor programms

T3 T4 T5 Unterbrechungswerk Prozessor - Zeit (Organisationsarbeit) Prozessor Zeit (Unterbrechungsspezifische Arbeit)

Definitionen: = T1 Durchlasszeit T2 = Latenzzeit T3 = Erkennungszeit = T4 Ausführungszeit T1+ T 2 = l,artezei t (umfasst nur den Ablauf des unterbrechungsspezifischen T1+T2+T3 = Reaktionszeit Antwortprogramms. Identifizierung der Unterbrechungsursache T3 + T4 + Ts = Unterbrechungszeit und Bereitstellung der Betriebsmittel sind zu T3 zu rechnen) T1 + T2 +T3 + T4 = Antwa rtzeit T5 = Rückkehrzeit T3 + T5 = Organisationszeit

l e t te t e e t lle Bi d 5 D fini ion charak ris isch r Z i interva

brechungs- Priorität Bestimmung der Unter­ charakteristische Zeitpunkte fixiert und dadurch brechungsanforderung mit höchster fünf Zeitintervalle T1 bis T5 definiert. Subpriorität. Die Zeitangaben für diese Intervalle können je Ausserdem muss die der Unterbrechungs-Anford­ nach angenommener Belastung des Rechners sehr erung zugeordnete Anfangsadresse festgelegt unterschiedlich sein. Die günstigsten Zeitangaben werden. erhält man, wenn man annimmt, dass der Ablauf der Unterbrechungsverarbeitung nicht durch andere Aktivitäten gestört wird. In allen anderen 6. Definition charakteristischer Zeitintervalle Fällen sind Angaben über die angenommene Belastung des Rechners mit anderen Aufgaben Bild 5 beschreibt ein Zeitdiagramm einer Unter­ erforderlich. Zu Vergleichszwecken wäre eine brechung. Im zeitlichen Ablauf werden sechs Auswahl von Standardaufgaben durchaus sinnvoll.

52 Choosing a standard high-level language for real-time programming

M.G. SCHOMBERG AERE, Harwe/1, England and P. WARD Plessey Radar, The Plessey Co, England

lntroduction

This paper is concerned with the problems of situation includes within itself standard solutions providing high-level language facilities for a real­ to some of the fundamental operations required to time project. lt covers particularly those formulate the solutions. Thus the programming features necessary for a real-time applications la.nguage points the way to the solutions by already programmer and does not consider the rather having solved some problems and laying the more special problems for the systems software foundations for the solution of the rest. programmer. The 'practitioner' point of view rejects the A large number of real-time projects are pro­ conclusions of this argument, not by denying the grammed entirely in assembly language for a facts but by pointing out their characteristic of variety of reasons. These range from necessity, only marginal improvemerits in comparison with due to space and time requirements, to simple more general-purpose languages, and considering prejudice. This paper assumes that the use of a other problems and constraints of greater weight. high-level language is justified for the project. The time scale for development of a new language Section 2 of this paper considers the alternative is long (from initial ideas, constructing the com­ approaches of using existing languages or writing piler, testing and assessing the value of the new special ones. Section 3 identifies the special features). A new language also implies re-training features necessary for a real-time language and of programmers and the writing of user manuals. how they can be achieved and in Section 4 a method Consequently it is not usually practicable to of selecting the most appropriate language for a undertake to do it within an already tight time hypothetical project is demonstrated. scale for a development project. Furthermore, the solutions to the problems involved will be discovered by people working in the project with General-purpose or special-purpose languages their individual prejudices, experience, capabili­ ties and potentials exerting a much stronger There seem to be two main schools of thought influence than the programming language. A man concerning the selection of a suitable high-level using a new programming language is most likely language for real-time projects. The first of to continue with design habits acquired during his these, which comes from the more academic previous experience with other languages: thus circles, implies the development of a special the potential benefits of a special-purpose language for almost every individual problem. language are weakened, and the effort which The alternative view, supported by this paper, would have to be expended to develop one is not favours the use of existing high-level languages judged to be justified. whenever possible. The 'academic' point of view is based on the use of the programming language not only as the means of communicating with the computer but Real-time features also the framework for thinking about the solution of the problem. On this basis they argue that an This section identifies the special features apt language will lead to a good solution, while an associated with real-time programming and then inappropriate one may lead to a poor solution. In attempts to show how they can be realised in addition, the special language for the particular more general-purpose languages.

53 Special features of a real-time language able to the programmer. There are three possi­ bilities: These are divided into three categories. 1. To provide the facility as an assembly code 1. Time-dependent features: those features subroutine which can be called from the which control and monitor the dynamic user program. system state. They include: 2. To provide a facility in the compiler where­ I/O control re-entrancy by in-line assembly code instructions can resource allocation parallel processing be used. This facility can be given a high­ storage control non-sequential level flavour by the use of macros. interrupt handling operations 3. To modify the compiler to provide a set of new language statements which ensure the 2. Time-independent features: those features necessary linking to either the operating which are mostly found in the solution of system or to a library subroutine that real-time problems but which are not performs the required function. strictly time-constrained. They include: The first alternative of using assembly code byte handling bit addressing subroutines is probably the easiest to implement list processing in- line insertion of code but the subroutine calling sequence will result in string handling some loss of object code efficiency. The other alternatives avoid this by generating in-line code. 3. General features: those features which are If the compiler permits the insertion of in-line not only important in the real-time field code then this can be achieved by a macro pre­ but also in other fields of computing. They processor. The chief penalties here are a include: reduction in the general legibility of the source modularity ease of use program and a lass of checking by the compiler. macros ease of program The desirability of enhancing an existing compiler data structures maintenance to include new language statements can only be well established judged in each individual case. The last three, although not strictly language 'features', are included to bring Time-independentfeatures out the importance that is attached to these aspects of a language. The above considerations lead to an unexpected In the above it is only the time-dependent conclusion. Those language features normally features which require communication with the associated with real-time programming are not, operating system. lt is therefore assumed that in fact, the most essential features when assess­ the operating system provides the necessary ing a language for a real-time project. Such 'hooks' to perform such operations as the schedul­ features can usually be provided by other means ing and suspension of tasks and resource alloca­ without undue difficulty. tion as requested by the 'user' programs. However, the language feature'provided by a general-purpose language that is least likely to match the requirements of a real-time application How these special features can be provided is its data structures. The ideal data structure will probably be different from orie real-time Having established what special features are application to another and requiring any combina­ necessary for programming a typical real-time tion of list structures, multidimensional arrays, . application it is possible to examine the means by Coral TABLE structures or the COBOL hierarchi­ which they can be provided. cal record structure, while, at the same time, Consider the problem faced by the program­ being influenced by data retrieval requirements. ming manager about to undertake the implementa­ PL/1 is the only language that approaches this tion of a real-time project. He has a computer, a degree of flexibility. However, in spite of this, general-purpose operating system and one or more real-time projects do get implemented and such general-purpose high-level language compilers. problems with data structures do get overcome as He must first identify precisely which real­ they arise; apparently without too much difficulty. time features are necessary for the project. lt is possible to describe data structures in a Those which only the operating system can pro­ long-hand manner if suitable language facilities vide will entail either modification to the existing are not available. operating system to provide them or writing a To conclude this section, it can be seen that new operating system. Those features which are all the special real-time features, except perhaps independent of the operating system are discussed data structures, can be provided without the need later. for special language development. The lack of A means must then be found of making the suitable data structuring facilities makes the additional features of the operating system avail- programmer's job more difficult but not usually 54 impossible. Some of the currently available selected computer. To have a professionally general-purpose languages provide adequate implemented compiler which has stood the test of facilities which enable enhancement to the level time contributes more towards the successful necessary for most real-time projects. It is achievement of a project than any number of therefore suggested that the use of such languages features specially designed for the project. This provides the most cost effecti ve solution to this is particularly so when such features can be problem in many instances. provided, perhaps less elegantly, by other means. Full error checking and unambiguous error reporting, comprehensive de-bugging facilities Graded assessment of high-level languages and a good user's manual are of prime importance in the use of a language in any project. '.fhese This section examines six commonly used features can, of course, be included in the languages for their suitability for a real-time language assessment criteria. project. They have been selected on the basis Table 1 illustrates this technique for a hypo­ that they include the most widely used languages thetical project. The main points that the table and represent a wide spectrum of applications. brings out are as follows Others, e.g. JOVIAL, should perhaps be included 1. The relative merits of each feature to each for completeness, although the purpose of the other feature, e.g. it is more important exercise is to illustrate a method of assessing that the language is easy to learn and use languages and not to do an assessment. than it should have 1/0 statements. 2.' How each language performs for each feature, e.g. FORTRAN and COBOL are Method of assessment easy to learn, whereas PL/1 is the most difficult. In order to carry out an assessment of program­ 3. Neither COBOL nor ALGOL can be consi­ ming languages for any project it is first neces­ dered for this project. sary to list an language features and other 4. PL/1 is the most suitable language for the factors which have any effect on the application. project. This list of assessment criteria is then grouped This method is both simple to use and under­ together according to their relative importance. stand and can be designed to any level of detail A typical grouping might be as follows: essential required. It is fairly objective in its approach features, highly desirable features, desirable and enables the value and effect of new informa­ features and possibly useful features. Each group tion on the choice of language to be readily is then assigned a grade range. For example, the assessed and leaves irrelevant arguments to be most important group is given a grade of 100, the discarded immediately. next group the range 50-99, and so on. Within this grade range each of the assessment criteria is given a particular grade to show its relative Conclusions importance compared with other criteria in the same group. Each language is then taken in turn This paper has sought to show that in many real­ and for each of the criteria is given a mark up to time projects it is more appropriate to use the maximum allowed for that criterion. This existing languages than to develop special ones. mark must reflect the capability of the language It is suggested that most time-dependent features to meet the criterion compared with the other can be realised without too much difficulty and languages being assessed. Once the assessment that it is more important to consider such aspects table is complete it is possible to carry out a as a good implementation of an existing language simple elimination exercise. which has the necessary data structures. The Any language which does not meet all the final section illustrates one way of selecting that essential criteria can immediately be eliminated. most suitable language for a real-time project. By totalling all the marks for each language the comparison between them can be made. Hopefully, the language showing the highest over-all total is the best for the job. Discussion Although the initial marking of features for a particular project must necessarily be subjective C. I applaud your courage in presenting specific and based largely on experience, once this has figures. been done the actual assessment process is probably fairly reliable. C. The results have little meaning, because the Other factors, however, influence the final weights can be changed to manipulate the figures. choice of language. Among these, and perhaps even more important than the language itself, is Q. What do you mean by dynamic storage in this the availability of a suitable compiler for the context?

55 TABLE 1 Language assessment for a real-time project

Max. points Fortran Cobol PL/1 Algol 60 Algol 68 Coral 66

Essential features Modularity 100 100 0 100 0 100 100 Bit /byte addressing 100 100 0 100 0 100 100 Sub total 200 200 0 200 0 200 200

Highly desirable features Data structures 85 0 85 85 0 85 50 Macro facility 85 0 0 85 0 0 85 Easy to learn and use 60 60 60 30 50 40 40 Good documentation and maintenace 60 60 30 60 30 30 30 Parallel processing 60 0 0 60 0 60 0 In-line code insertion 60 0 0 0 0 0 60 Usage 50 50 50 30 30 0 10 Sub total 460 170 225 350 110 215 275

Desirable features Dynamic storage 40 0 0 40 40 0 40 1/0 statements 40 40 40 40 0 40 0 String handling 40 0 40 40 0 40 0 List processing 30 0 0 30 0 30 0 Floating point 20 20 20 20 20 20 20 Sub total 170 60 100 170 60 130 60

Possibly useful features Free format 9 0 0 9 9 9 9 Machine independence 5 0 5 3 3 4 3 Recursion 1 0 0 1 1 1 1 Sub total -15 -0 -5 -13 -13 -14 -13 TOTAL 845 430 330 733 183 559 548 Implementation features Compiler available 90 Compiler usage 90

A. The program's facility of influencing storage C. You should also take into account allocation. a) the experience of the programmer b) the size of the computer. Q. How would you take into account the quality of the programmer? C. Learnability should be taken into account in language design. A. We had this in mind in 'easy to learn and use'.

56 Use of high- and low-level languages in a real-time system

J. STENSON Plessey Radar, The P/essey Co, England

lntroduction high-level ones. Either or both of these improve­ ments may be made. This paper discusses briefly some of the argu­ When the decision between high- and low-level ments for and against the use of high-level languages had to be taken we had time-scales to languages in a real-time system. Then it goes on meet and limited space and time in the system. to describe the results of efforts made by the The rest of the paper shows how we decided Plessey Company to use a high-level language in between high and low languages, and the results parts of a real-time operating system. of our choice. lt is hoped that our experience will be interest­ ing to everyone who is looking at the use of high­ level languages in real-time systems. 2. Brief system description

This system is a multicomputer Air Traffic Con­ 1. For and against the use of a high-level language trol project. The computers are of two main types, and not all have access to the same Consideration of whether to use a high-level facilities - for example, some have access to language rather than a low-level one is influenced magnetic tape decks, some do not. All the com­ by the following factors: puters can communicate with a common store in 1. Writing in a high-level language is much which the data base is held. quicker. Each computer receives one interrupt at 2. Coding errors are less frequent. regular intervals, and from this interrupt all the 3. Testing is often much quicker at the off-line system timing is derived, although there are stage. other significant times, e.g. radar scan time and 4. Documentation is sometimes simpler. data link time, which have to be observed. 5. Handover of the program is easier - The system can be considered as having two whether between programmers or to the parts, a 'foundation ', which would be nearly the customer. same whatever the system were used for, and 6. Even an efficient high-level language 'application software', which is concerned only usually needs more space and more run with the air traffic control functions of the time than a lower-level one. system. 7. If obscure bugs are found on line, the pro­ The 'foundation' consists of an operating grammer will probably have to look at the system providing scheduling, communications, machine code instructions to trace them, peripheral handling, reconfiguration, fault and this is easier from a low-level detection and location. Parts of this have been language than a high-level one. implemented during the past year, and it is from A balance has to be reached between speed of this implementation that the following information program production, achieved by using a high­ has been drawn. level language, and efficiency of code, achieved by using a low-level one. This is a very difficult decision because programmer time is always 3. The operating system expensive, and any means of reducing it is worth­ while, but time and core space in most real-time The operating system contains programs which systems are precious. perform the following functions: The solution may be to make high-level 1. Schedule tasks in every computer in languages more efficient, so the object code they system. produce is nearly as good as a programmer can 2. Provide communication between the compu­ write. Or it may be to improve low-level ters in system and the common store. languages to incorporate some of the features of 3. Handle peripheral equipment - teleprinters,

57 punches and readers, magnetic tapes. Also held in every computer, MINICORAL for those the 'control panel', which is hardware held in only a few. To a certain extent this was device controlling the configuration of the done but there were a number of weighting factors system. to be applied. These were: 4. Control andinformation service to the 4. Any program in the XL6 --must be in operator. This program is known as The assembler. Director. 5. Some programs which appear in every com­ 5. Detect faults. puter in system have very low priority, and 6. Load programs. if their run time is a little bigger than it 7. Aid on-line testing. need be it may not matter very much, since the program will only run when there is spare time anyway. 4. Available languages 6. Some programs which appear in every com­ puter are run on rare occasions only in the fu this system we use two types of computer, the operational system. Therefore their space XL4, a double address machine, and the XL6, a and time need not be optimised to the same single address, less powerful computer . For the extent as others. XL4 we have a high-level language, MINICORAL, Starting from the position that we wanted to a subset of CORAL, andXA L, an assembler. use MINICORAL if possible to reduce program For the XL6 we have XAL only. production times we arrived at this split between MINICORAL can be a very efficient high-level MINICORAL and XAL: language. An experienced programmer writing with store economy in mind can achieve a 1.1: 1 MINICORAL XAL size ratio - we have tried experiments and it can be done. But, of course, a less experienced pro­ Scheduler grammer can produce much worse results than Communications that; 2: 1 is about averag,e. There are very good Control Panel Handling Teleprinter Line off-line testing aids associated with the language, Printer and this is a great advantage. Paper Tape Handling XAL is a mnemonic assembler with very good Magnetic Tape Magnetic Tape macro facilities. lt is easy to learn, but there Handling (XL4) Handling (XL6) are fewer off-line testing aids associated with it, Director (XL4) ) and therefore programs can take longer to debug. Director (XL6 Fault Detection Really experienced XAL programmers have very On-Line Aids On- Line Aids little difficulty debugging their programs. Reload using XL4 Reload from XL6

5. Available people

The programming team contained people with a 7. Review of each program wide range of programming skill. They ranged from those with 5 years' experience to those with Each of these programs is considered below. The none at all. Our trainee programmers were used arguments for using the particulat language are mostly on the MINICORAL programs. given, and where MINICORAL was used the results are considered. Where XAL was used less information is included. 6. Split between high and low-level languages There are two areas, Magnetic Tape Handling and The Director, where comparison between a When we looked at the list of tasks to be MINICORAL and a XAL version of the same pro­ performed (Section 3, 1-6) some points were gram can be made. lt is not a direct comparison, obvious immediately: because the MINICORAL versions were for XL4 1. Some programs would have to exist in every computers and the XAL for XL6. The XL4 has computer in the system (scheduler, com­ more powerful instructions than an XL6, so one munication, on-line aids, fault detection) . expects to find fewer instructions used in this 2. Some were restricted to only a few compu­ computer. ters because of the arrangements of the hardware (magnetic tape handling, control panel handling). 7. 1 Scheduler, communication 3. From the nature of their design some pro­ grams needed to appear in one (or only a These programs were written in XAL because few) computer only (The Director, Reload) . they are used in every computer in system, and A simple split would be to use XAL for programs therefore space is important. They are used con-

58 stantly in every cycle of work, and therefore time the right decision. The ease of production and is important. We considered that any increase of documentation justified the use of the high-level space or time could not be allowed, and they were language, and no significant time penalty has been written by skilled assembler code programmers. paid.

7.2 Teleprinter, /ine printer and paper tape handling 1.5 Fault detection

These were written in XAL because MINICORAL This program is scheduled at the end of the lowest does not offer particularly good facilities for this priority list of tasks. lt is called when all other type of peripheral handling, they were short pro­ work has been done, and having been completed grams anyway, and some were for the XL6. We adds itself to the bottom of the list again. Thus if did not spend very long over this decision - peri­ there is very little work being done in the compu­ pheral handling of this type seems to demand an ter this program is run frequently, but as the assembler code. work load builds up so the calls become fewer. As the program will only be used when the workload allows it, the time overheads incurred 7.3 Load if it is written in MINICORAL are not serious. The program resides in every computer in sys­ These parts of the load programs housed in an tem, and therefore space is a matter of concern. XL6 were written in assembler code, but where Despite the consideration of space the pro­ they were housed in an XL4 they were written in gram was written in MINICORAL to reduce time­ MINICORAL. 'l'his is because they are used scales. The space occupied is more than we comparatively rarely in the operational system allowed for when the program was designed, and (probably less than once every six hours) although we are faced now with a need to look through the they are heavily used during program develop­ program to find ways to reduce the space used. ment. lt seems more important in a case like Nevertheless, the program was ready on time this to ensure that the program can be maintained and it can be used in its present overlarge state easily and handed on from one programmer to for a few months before the 'applications' pro­ another than to achieve minimum space or time. grams increase in number and its size becomes Space bad to be considered, because there is a problem. limited space in the System. The programs did This is where the judgement between the two not occupy an excessive amount of core (0.7 Kin alternatives is difficult - we did achieve a result 4 computers of 64 Kcapacity). on time, which is important, but the excessive lf we had to make this decision again we would size of the program is just as relevant. make the same one. Any program used at a very Summing up, it is apparent that this MINI­ low rate is a reasonable vehicle for an experiment CORAL program is less successful than the two in using high-level languages. previous ones.

1.4 Contra/ panel handling 1.6 On-line aids

The program resides in one computer only in the On-Line Aids will be used most frequently during system, and is called every cycle. No significant the system development stage, at which run time amount of processing takes place unless the and space overheads are not particularly signifi­ operator uses the System Control Panel to re­ cant. (lt is possible to alter real-time situations configure the hardware in the system. This should just by using on-line aids, but this situation is be a rare occurrence - major reconfigurations unlikely to be made worse by longer run times.) involving computer changes should not occur more The aids will be used occasionally in the opera­ than once in 24 hours, and minor ones should tional system, but not often enough to make run­ happen less than once per hour. time overheads significant. Like 'fault detection' In these circumstances no serious penalty in (Section 7. 5), they exist in every computer in overheads will be paid at run time if the program system, and space is important. is slightly slower than it need be. lt was, there­ For reasons of speed of production, allied to fore, written using the MINICORAL compiler. a conviction that MINICORAL should be a good The program was written by experienced pro­ language for tasks like this, we decided to do two­ grammers. lt was completed quickly and with thirds of the total work in MINICORAL. very few unforeseen difficulties. lt operates well The project suffered throughout its life from within the time available to it, and whenever the changing manpower, and was frequently under­ program has been run it has given satisfactory strength. Despite these difficulties it was com­ results. pleted on time: but its size is excessive. We This was another area where we feel we made attribute this to its low staffing level leaving no

59 time for a careful examination of the coding of instruction set is more powerful. each module to ensure that minimum space was used. Like 'fault detection', we now have to carry out this examination and reduce the size of 8. Conclusion the program. lt is possible that the same troubles would In this multi-computer system it was possible to have been met if we had elected to write the pro­ use a high-level language in those areas which gram in XAL; in fact, it might have been even were not common to every computer in the system. worse. When a high- level language was used in an area lt is difficult to tell with this project whether which was common to every computer the results it would have been better to write in a low-level were less successful, although it is likely that the language. lt seemed to be a function of the low fault did not lie with the compiler. manning levels rather than an inherent difficulty From the experience gained in this system, in using a high- level language that caused the designers may well be less sceptical of the growth in size. wisdom of using high-level languages in real-time system than they have been in the past.

7.7 Magnetic tape handling Acknowledgements Only 2 of the XL4 computers are expected to use magnetic tape decks at any one time and they will This paper is based on the work done by Plessey not be in constant use. This was an obvious place Programmers in System Implementation with the to use MINICORAL and it has been used very help and collaboration of members of the Royal successfully. At present the XL4 version is esti­ Radar Establishment at Malvern. mated at 2 K (with 75% completed, so the estimate should be reliable). The XL6 version, written in XAL because Discussion there is no other choice, is 2.2 K. These figures show a very close correlation Q. You remarked that the most successful pro­ between the MINICORAL and XAL versions. grams are those that are run least often. Is this because these programs are tested less thoroughly?

1.8 Director A. Not quite, but perhaps because they are less prone to interactions from other debugging, and The Director has two parts, one of which resides errors in them have less far ranging conse­ in every computer in system, the other in one quences. XL4 and XL6 only. The part that occurs in every computer in system was written in XAL for C. Good programmers want to get all the power economy. The control part, in one XL4 and XL6 of the machine, so they program in assembler. computer, runs once every cycle. This means But the very best programmers want to get this that size and run time are not critical, although in higher level languages. they cannot be ignored. The program for the XL4 was written in MINICORAL and that for the XL6 C. Even when using low level languages we do not in XAL. allow our programmers to use 'tricky code '. With The sizes of these programs are: XL4, 2.2 K; high-level or macro languages one should accept XL6, 3.6 K. This is a very satisfactory result - some overheads and inefficiencies which result XL4 programs should be smaller because the from enforcing programming standards.

60 Workshop on basic design principles of operating systems

Chairman: Dr I.C. PYLE AERE Harwe/1, England

The discussion was concerned with operating sys­ to define an interface between application pro­ tems, their definition and programming. The grams and operating systems for use with usefulness of the idea of virtual machines was CAMAC. This is guided by the concept of a virtual agreed, although the concept itself is not clearly CAMAC controller and the virtual machine concept specified. On the issue of programming language, is found valuable in the work. the question was asked whether operating systems must be written in languages different from those E. Is a real-time system only a small- scale used for general-purpose real-time or process batch system? control; and if so what are the essential differ­ ences? L. No, because the programs do not cooperate.

M. A language defines a machine. The definition Operating systems and virtual machines of any programming language must imply a virtual machine, which can run programs written L. Is an operating system the 'glue' which holds in the language. together the facilities that a user has at his dis­ posal? Or is the operating system that which is performed by programs rather than carried out Programming languages by the system operator? Different people seem to use the phrase for anything between these M. The operating system is an extension of the extremes. hardware and has to be able to interact with it in very detailed ways which may not be appropriate B. Looked at from the outside, e.g. a process for application programs. lt should therefore be control application, we need to estimate the programmed in a different way. stability of a computer system with respect to changes in J. The time factor is an important difference a) The environment which may affect the between the language chosen for operating sys­ operating system such as new kinds of tems and application programs. The operating devices. system is called frequently in comparison with b) The application programs to be executed, applications programs and therefore must be such as new control algorithms. written in very efficient language. Regarding the hardware plus operating system as a virtual machine helps us to do this. X. This is not uniformly true for operating systems: parts are used with different frequen­ P. There are three different aspects of an opera­ cies. ting system, which one should clearly distinguish in discussing the levels of a virtual machine: L. Not only do we need to consider the basic a) The facilities through which the user can operating system primitives, we need to realise use the hardware of the computer system that the important structure in a real-time more easily. system is a process rather than the program. b) The facilities through which the user can We need programming languages in which the control interactions of his own tasks. idea of a process is clearly expressed. c) The facilities through which the operating system can control the user program to P. lt is important to distinguish between a 'real­ share resources between several user pro­ time language' which incorporates timing facilities, grams. and a 'language for real time' which is suitable for use in real-time programming while not having B. An ESONE Working Group is engaged in trying any specifically real-time features. CORAL 66 is

61 one of the latter. construct them. A language for operating systems should have more privileged features so that the H. An application package should look like a application programmer has a subset of the same virtual machine when it is finished, therefore language. you should have a common language with which to

62 COMPONENTS OF REAL-TIME SYSTEMS

Chairman: Prof. Dr R. BAUMAN

63

Basic supervisor facilities for real-time

1.C. PYLE AERE Harwell, England

Present address: Department of Computation, University of York, England

An analysis of the supervisor facilities in a num­ strong enough, we have to define the facilities to ber of real-time operating systems leads to the be provided by the supervisor with great care specification of a number of basic facilities. and introduce a suitable notation by which they These cover task handling, resource allocation, may be specified in a CORAL program. The latter and inter-process communication. The para­ part, the syntax, is not difficult. The major part meters required for these facilities include of the problem is in specifying the facilities. identification of tasks and identification of peri­ pheral devices. The handling of I/O may be treated as an autonomous process to carry out Supervisor facilities the transput. with inter-process communication transferring the data to the main process. There are three principal categories of supervisor facility: Task (or Process) facilities; Resource Allocation facilities; Communication facilities. lntroduction The first of these is actually a special resource allocation (since it is concerned with the alloca­ Several papers at the First European Seminar on tion of the processor in the computer), but it is Real-Time Programming discussed the interface sufficiently distinctive to warrant a separate between the real-time programming language and category. The third covers what is normally the real-time operating system. In our investiga­ called I/0, and also inter-process communication. tion of CORAL 66 as a programming language for I/0 devices may be simple slaves to the main real-time work, on a PDP-11 with the Disk processor, requiring simple communication Operating System (DOS), we ha ve been seeking to facilities, or they may have autonomous capabili­ determine a suitable set of basic supervisor ties in which case they are best regarded as facilities which we could implement by elaboration separate processors running in parallel with the of the DOS Monitor. Our hope is to establish a control or computing processor(s), and the com­ standard interface between a running CORAL 66 munication between the processes propelled by program and the supervisor (or run-time opera­ these processors is inter-process communication. ting system) controlling it. The principle of selection of facilities for a CORAL 66 as officially defined (Woodward, prospective standard must be to keep the list Weatherall and Gorman, 1970) does not require a short and simple. The supervisor occupies valu­ run-time operating system. In practice, programs able store during run time, and must not be made written in CORAL normally will use a run-time unnecessarily elaborate. If the standard covers operating system (i.e. a supervisor program) so more than the bare minimum the supervisor pro­ that the program as written does not have to be gram will provide the facilities whether or not concerned with the details of peripheral handling, the application program requires them. Any and to permit multiprogramming. This is an enhancements needed to elaborate the supervisor extension of the concept of a library, which is in facilities can be included in Ubrary procedures to official CORAL 66. The other point about the be loaded only when required, which call on the official non-insistence on a supervisor is that it supervisor for the primitive facilities. Accord­ enables the supervisor itself to be written as a ingly, we proceed by giving a list of facilities CORAL 66 program. This has been done for the which appear to be primitive. Myriad Computer, making the supervisor called The entry conventions for supervisor calls will MOLCAP (Jackson, 1970). have to be settled for each particular implementa­ An attempt to standardise supervisor calls tion, but the standard must specify what para­ amounts to an extension of the CORAL 66 defini­ meters are to be transferred for each supervisor tion, by establishing certain facilities which call. Some computers will have an established would then be common to all CORALS at the supervisor call instruction, others will use a appropriate level. In order to make the definition trap or entry to a standard location, or force

65 some special exception to occur. The standard any tidying up necessary. The local termination cannot expect to lay down which method shall be would be a procedure, which is activated by the used, but can reasonably assume that there will supervisor immediately after a supervisor call to be just one general method of supervisor call in terminate. lt would have one input parameter, each implementation, which is different from an being the termination code. There has to be a ordinary procedure call (for example, to cause a supervisor call to pass this local termination change of processor state where there is a differ­ procedure to the supervisor for the task. If there ence between user mode and supervisor mode). has been no such procedure specified before termination, then the supervisor removes the task immediately after a supervisor call to terminate; Task facilities otherwise it activates the local termination pro­ cedu�e (after removing the record of it from the The facility which almost all supervisors will task entry), and on return from it removes the provide is 'generate task'. This will activate an task. Thus we have a supervisor call already loaded program to operate on given data in the store, at a specified execution priority; set task termination procedure (p) the supervisor will provide the identification for with one parameter (of type PROCEDURE the task. Thus there are four parameters, three (INTEGER VALUE). input and one output: A task in a real-time system may require a entry location (a destination) delay of a period of time. We therefore need data origin (a pointer) wait (number of time intervals) priority (an integer) task identification (output, probably a pointer). where the magnitude of the time interval will be system-dependent. The priority may be omitted: the default value will be the priority of the task issuing the super­ visor call. There may be rules prohibiting a task from generating other tasks of higher priority Delayed activation than itself. Improved ideas on task scheduling may lead to a better method of regulating the allo­ A powerful technique, especially useful in real­ cation of processors to processes, but at present time for dealing with time-out situations, is a the use of a priority number is the most suitable. delayed activation which can be cancelled. With The next and most fundamental supervisor an activate which takes effect after a specified facility is 'terminate task'. Every program needs time delay, the time-out action can be easily set to be able to specify its dynamic end. With com­ up, leaving the supervisor to look after the puters which have a 'stop' instruction, the first timing. The additional facility which is necessary rule for programmers is not to use it, especially is to be able to cancel the delayed activation, if in real-time work. There can be two variants of the awaited response arrives in time. Since this this supervisor call: terminate own task (without would be the normal situation, the supervisor parameter) and terminate other task (with other must keep its delayed activation requests in a way task identification as parameter). This introduces which permits efficient cancellation. the need for task identification and the problem of This can be treated as a combination of the naming tasks. The standard cannot solve the supervisor calls to acti vate and wait (acti vate the problem, but must assume that a solution is time-out action immediately, but put an appropri­ chosen in a particular implementation, and any ate wait at the beginning of the task). The cancel restrictions consequent on that solution limit the is then simply a call to destroy the task, which range of other tasks which can be controlled. The will take place while it is in the wait state. There two variants can be viewed as the same super­ is a danger of trouble if there are other waits in visor call, with a default value for the parameter the time-out action task, since the task might if it is omitted, being 'self'. For a discussion of then get destroyed in a partially completed state. the problems of task identification, see Taylor This can be solved by the discipline of insisting (1972). that such a time-out action contains no further As an alternative method of terminating a task, waits, although it may in turn activate a further but denoting an abnormal or exceptional dynamic task (which would not get destroyed when the end, it is desirable to have a separate supervisor response comes). call: 'abnormal termination '. This applies only to the current task, and carries a parameter which can express the nature of the abnormality Task synchronisation and interrupts or exception. A task which may be subject to abnormal The well known primitives for handling semaphors termination from another task should be gi ven the permit a task to be held up at defined points until ability to specify its own local termination, to do another task gives it the go-ahead:

66 Secure (semaphore in*) is no longer needed. A subsequent reservation Release (semaphore in*) will not necessarily get the same device, assuming that there are several of the same type forming There are arguments in favour of a further super­ the resource. Depending on the nature of the visor call, which cannot be implemented by use resource, different things may be done when the of the above: resource is claimed and secured. Thus we need two supervisor calls: attempt to secure (semaphore in*, status out*) Reserve resource (resource type in, identity This is equivalent to secure if the semaphore out) would permit the task to proceed, but otherwise Discard resource (identity in) gives the status of the semaphore without suspend­ ing the task. Releasing a semaphore gives a To handle the exclusive use of a resource, we stimulus to the task which had previously made a need to use a semaphore which will control secure for it. access to that resource: Stimuli can arise from outside the computer (hardware interrupts) or from other running tasks. Prepare for multiple use (identity in, sema­ The effect of the stimulus is not directly to create phore out) a task, but to resume execution of a task which must previously have been set up and suspended The exclusive uses are then controlled by the use awaiting the stimulus. In order to deal with of the semaphore. critical sections, it is necessary to be able to inhibit the response to stimuli for certain periods of time. Thus the primitives required are: Communication

Set response to stimulus (stimulus identity in, We assume that the executing task may communi­ semaphore out) cate with a number of data sets outside itself, Inhibit response to stimulus (stimulus identity which may be accessed sequentially. Streams of in) data will be either input or output, and may be Permit response to stimulus (stimulus identity buffered. A stream which is output from one task in) may be input to another task, or after it has been closed, to the same task. Buffering implies In the task to be performed, it is normally held having separate autonomous tasks (usually very up by the semaphore; it starts in response to the simple) complementary to the main task: if the Stimulus, and must return to the semaphore wait main task puts information to an output stream again if it is prepared to respond to further for printing, then an auxiliary task has to read stimuli. the output buffer and print what it finds there. The principal problem about this technique is We have to consider input output for different identifying the stimuli between separate processes. categories of devices, depending on the nature of In a simple system, the natural solution is to the information they transmit in an elementary adopt a system-wide assignment of stimulus type operation. Basically, there are character devices numbers corresponding to distinct physical inter­ (e.g. teletype), word devices (e.g. ADC samplers) rupts at the hardware level. and block devices (e.g. disk). For character devices, it is usual to deal with streams of characters, and it is more economical to specify Resource allocation the source or sink separately, rather than with each individual input or output character The allocation of resources other than processors and main store will assume that they are discrete, and have in general to be allocated in two stages: Set source (device identity in) shared and exclusive. Every resource has Set sink (device identity in) initially to be reserved, and it will in principle Input character (character out) be shared. This means that there need be no time Output character (character in) delays on reservation. A claimed resource can then be secured for exclusive access, and must For the character devices, it is often desirable be released when exclusive access is no longer to be able to translate the character code, so that needed. The resource must be discarded when it a uniform internal character code can be used, but this is more economically done by a library procedure on a complete line of characters * The suffixes 'in' and 'out' distinguish input and together. Words are input and output from expli­ output parameters of the supervisor call. citly identified devices:

67 Input word (device identity in, word in) Conclusion Output word (device identity in, word out) This paper has begun the process of specifying For block devices, a buffer area is needed, which the supervisor interface, by concentrating on the has to be set up by the program in a special areas of tasks, communication and resources. The interfa�e does not specify any facilities refer­ format, and then given as a parameter in the supervisor call. This can include the specifica­ ring to protection between processes or store areas, because it assumes that this matter is tion of which area on the device is to be used, and the direction of the transfer: handled entirely within the supervisor, and needs no further information or stimuli from the work program. lt has not covered store allocation or Put block (buffer in) file structures, so is far from complete for a full operating system. Likewise it does not include backing store usage or swapping facilities. Nevertheless, facilities such as these will be Storage allocation needed within some real-time operating systems. At the First European Seminar on Real Time No run-time supervisor facilities are proposed Programming, it was thought premature to make for allocation of main storage. This is a deliber­ such an attempt. lt is still premature to expect a ate restriction on the flexibility of the operational standard to be widely adopted, but it is not too system, which corresponds to the essential early to start thinking about the problem. characteristics of the situation, at least at the present state of the art. The argument for exclu­ ding them rests on the requirement that the real­ 1. JACKSON, K., 'Myriad Library Part 2.1 ', RRE (1970). time programming language be predictable. 2. TAYLOR, J.R., 'Control of names in systems with 1f there is run-time allocation of storage by dynamically created objects', AERE-R (1972). the supervisor, then a general strategy has to be 3. WOODWARD, P.M., WEATHERALL, P.R., and adopted to deal with block of various sizes and GORMON, B., 'Official Definition of CORAL 66', HMSO unco-ordinated requests and releases. Conse­ (1970). quently store fragmentation is a real danger, and from time to time an unpredictable store jam will arise; in this event, either the system will be brought to a complete halt or there will be a signi- ficant time delay while there is some reassign­ Discussion ment of storage. The implications of this decision are that the Q. Why do you have no absolute delay? allocation of storage is done at load time, with the user's program thereafter responsible for A. The wait specified is absolute. There is no how the store is used. Thus, for example, the relative delay because it can be derived from an program can state that it needs a stack, and must absolute delay. specify to the loader an appropriate maximum size for this stack. Space will be allocated C. In my applications, delay timing has not been permanently for the maximum size stack, and critical. Swapping can cause timing problems, within this the user program keeps its stacked though. variables and its own stack pointer. Separately, the program can state that it needs some buffers Q. How do you deal with random access devices, of a certain size, and must specify to the loader e.g. disk or other backing store? an appropriate maximum number of buffers which can even be concurrently in use. Space will be A. Not in the level of supervisor I have described, allocated permanently for the maximum number but at a higher level. (Similarly for CAMAC.) of buffers, and within this it is up to the user program to control its own use of the buffers, Q. Does this also apply to shared devices such as and take its own action if the situation arises shared typewriters? when all buffers are in use and it needs another one. A. Yes: the (reentrable) program to handle them In other words, the organisation of store pro­ would be written to use the supervisor facilities vided is fixed at load time as far as the super­ described. visor is concerned, and any dynamic usage is directly controlled by the user program. This is C. I have found that this tends to cause rather in accord with the views expressed at the First high overheads. For this reason I would include European Seminar on Real Time Programming the facilities in the basic supervisor, although (pages 31 and 32, speakers D and G). conceptually they belong at a higher level.

68 programs without Q. How do you wait for events? Q. How do you have reentrable storage? dynamic A. By semaphores. care of its own storage A. Each task must take allocation.

69 Software aspects of the UMIST hybrid

J.N. HAMBURY Messerschmitt-Bo/kow-8/ohm GmbH, W. Germany

1. lntroduction 2. Hybrid software

The basis of the software developed for the hybrid The principle followed has been that a user pro­ computer was a field-proven, multi-access digital grams the initial and terminal regions [ 1 l (prob­ computer, the PDP-10. The software supplied by lem set-up and processing of results, respect­ the computer manufacturer was extended to ively) in FORTRAN, supplemented with an addi­ service multiple analogue computers, treated as tional library of Hybrid 1/0 Subroutines. These advanced peripherals by the digital. The software Subroutines operate by making 1/0 requests on a was developed as a team effort by five different Hybrid Service Routine [ 2 l, which was added to people, taking the approximate equivalent of the service routines (or drivers) for the standard 3½-4 man-years. lt was carried out during a peripherals in the monitor. The dynamic region period of about 1½ years, but it is still being (when the analogue computer is in compute mode extended and improved. and hybrid function generation may take place) is The software implemented for the PDP 10/Cil75 programmed partly with a set of macros and hybrid computer can be divided into three general partly in FORTRAN. The former are required categories: for 1/0, timing and synchronisation between the 1. Extensions to the PDP-10 Time-sharing analogue and digital computers, and the latter for Monitor. calculations. 2. Hybrid packages to be used in the imple­ The 1/0 Subroutines (FORTRAN), Hybrid mentation of applications. Service Routine and Hybrid Macros are shown as 3. Diagnostic routines to check the perform­ blocks in Fig. l, which indicates the interconnect­ ance of the system. ions between the various packages involved in the ltem 2 includes three languages intended to hybrid software. The other packages fully imple­ assist hybrid problem set-up and testing. These mented are the Hybrid Diagnostic and the Hybrid were originally formulated during work on the Interpreter, which is employed during problem previous Elliott 903/Ci175 hybrid [1 ], but were testing. extended for the PDP-10 implementation. A considerable amount of investigation has The most important aspect of the hybrid soft­ been devoted to Terminal Booking and Interface ware philosophy has always been to make problem Allocation. Typewriter terminals and analogue development as easy as possible. Tqe user must computers are reserved on booking forms, where inevitably contend with a great deal of familiarisa­ the type of use is indicated - hybrid, computer tion and could not cope with the additional problem aided design (CAD) or program development. A of critical real-time demands on a time-sharing limited number of configurations are available, system. Just as a multi-access terminal user because the research demands cause bottlenecks appears to have the complete digital power avail­ to be encountered (e.g. disk space) and it is able, each hybrid user must feel that he has impracticable to permit reservations to exceed independent access to the system and must be the capacity of the system. Typewriter bookings unaware of the complicated organisation involved are enforced by hardware connections adjusted in servicing the other hybrid users, displays and by the operator, and disk space is restricted by all the standard peripherals at the same time. lt software. An allocation of interface components, is very important that the user should avoid required for a particular problem, is reserved learning assembly language (as there are 366 at the beginning of run-time by means of a conver­ instructions on the PDP-10). Thus a high-level sational program (ALLOC), included with the language must be provided, without adding an Hybrid 1/0 Subroutines. Future development will unacceptable overhead to the solution time. enable this to be carried out earlier so that con-

70 Automatie hybrid Analogue problem __ ...., computer preparation assignment (hybridcompiler) and checks ! t t Problem Application configuration Application xecution program for program for requirements set up and 1- __ { at ] i nterface & control of dynamic region ·nterrupt analogue hybrid problem hybrid macros level -!- J. Terminal Hybrid {all ] booking . component Hybrid Hybrid ,. input-output r------blocks and i nterface ava il- diagnostic interpreter subroutines - �xecuted a 11 ocati an abilities (FORTRAN) 1n user mode ' 1 1 1 console assignment 1 . xecution -i;: Hybriddevice executi ve service r------r---- - { mode interface routine within the j connections man itor

I-0 bus ·� via GP 10 to - /hybrid interface

Fig. 1 Organisation of hybrid software flicts do not arise. critical response demands of the dynamic region. Automatie Hybrid Problem Preparation (Fig.1) The user jobs are not executed strictly in has also been studied in collaboration with the rotation, but are serviced in a variable manner British Aircraft Corporation. lt was apparent according to their run-times and core occupancies. that such a facility would save considerable Since they are not critically time-dependent the preparation time, especially as the generation initial and terminal regions are executed as user and execution of the hybrid object program (for jobs and take their turns with CAD and compilation set-up and checking) would be performed by the jobs. same digital computer, but too much support effort is required to enable the Centre to imple­ ment a hybrid compiler at present. 4. Hybrid service routine

The function of this module of the Monitor is to 3. Priority structure perform non-critical, buffered transfers between the digital and analogue computers. lt has been A flexible priority structure is provided by the designed to conform, as far as possible, with the PDP-10 digital computer. The levels are as standard 1/0 procedures. follows: When an initial region job requests a number 1. 8 hardware interrupt levels. of transfers by calling the 1/0 subroutines, the 2. Time-sharing monitor, including the hybrid latter transform the FORTRAN parameters into service routine. interface addresses and converter codes. The 3. User jobs. transfer is initialised, the addresses and codes More than one device may be connected to each are placed in buffers, which may be accessed by hardware interrupt level. lt is possible to attach the Hybrid Service Routine (HYDSRN) and an input a special response routine, written by the user, or an output request is made to the Monitor. This to any priority interrupt level [ 3]. A request is causes the execution of a section of code common made to the Monitor (by a user job) to connect a to all peripherals, followed by a section of the designated peripheral to its response routine, HYDSRN, which sets up the transfer of the first which is subsequently executed when an interrupt entry in the first buffer by generating an interrupt. occurs. This technique is used to satisfy the An interrupt is used to indicate the completion of

71 every individual transfer to the HYDSRN, which by the following considerations: then performs the following transfer. This 1. Conformity with the Monitor by the use of method was chosen, although the interrupt common I/0 code and programming uni­ response time may exceed the hardware conver­ formity. sion time, for conformity with the standard 2. Servicing multiple non-critical hybrid jobs procedures. together. The HYDSRN implemented initially could only 3. Consistent control of the single interface perform transfers to one analogue console at a and protection of transfers in EXEC mode. time. Thus only one hybrid problem was running lt is also possible to perform transfers from at any time, but it operated concurrently with all a user job in USER I -0 mode, a technique the time-shared terminals. This software enabled involved in critical operations during the dynamic all the other hybrid packages to be developed and region and in simple interface diagnostics. Both the first problems to be tackled. The initial cases involve communication with only one HYDSRN was later extended to organise and queue analogue computer. lt is concei vable that concurrent requests for transfers to more than multiple console I/0 could have been performed one analogue console. These cannot actually be by a similar method, by placing queue handling in performed simultaneously because only one hard­ the re-entrant FORTRAN run-time library, but ware interface (GP-10) is used. An initial this would have sacrificed protection and version of the multiple console service routine conformity, without considerable simplification. has been run. lt is now being re-specified in the An alternative possibility would have been to light of experience gained in prelimin?.ry trials purchase a separate GP-10 interface for each and feedback from the use of the single console analogue console, thereby avoiding the queuing system. problem and to program in USER I-0 mode. The development of the two versions of the HYDSRN has been proceeding over a period of 1¼ years with only one systems programmer work­ 5. Hybrid packages ing on it at a time. This period has been so pro­ tracted because it included familiarisation with 5. 1 Hybrid input-outputsubroutines the design of the Monitor and joint hardware­ software negotiations on the final design of the These subroutines were used for programming interface. Extending the Monitor presented a the Hybrid Interpreter and Diagnostic, as well as problem because of its complexity, although it is the initial and terminal regions of problems. well documented, and could only be undertaken They are summarised in Table 1. by experienced systems programmers (who were This form of definition has been found straight­ often required to assist with unrelated problems forward for familiarisation and application, and on the system). is consistent with the component identification on The development of the HYDSRN was justified the analogue and logic patch panels. The

TABLE 1 Transfers Mode Fast Analogue (A) Slow Analogue (A) (using ADC, DAC or using DVM for Logic (L) DAM) input RESET RLTRUNK RATRUNK RAMP HOLD SLTRUNK SA TRUNK RPOT COMPUTE SDAMPOT RSUPPLY POTSET RTRUNK RITER SPOT HITER TIMESCALE UNTIMESCALE ABBREVIATIONS: R = read s = set PARAMETERS: MODE Console number only TRANSFERS component numbers and values, number of transfers, console number

72 principle of operation has been briefly described with the HYDSRN. A suite of dummy 1/0 sub­ TABLE 2 routines has also been provided for problem test­ Number of ing. executable The development of this package has been Macro Function computer fairly straightforward as it was based on experi­ instructions ence obtained on the previous hybrid. Hardware definitions were modified during implementation ADCIN Read pair of analogue 6, but invol- and all the programming was in assembly (IFADD, values with interface ves loop DUPLEX) address IFADD and store until conver- language. The complexity of the flowcharts was in location DUPLEX sion completed increased by the flexibility of the interface, since at every access to the transfer subroutines the DACOUT Set pair of analogue 2 component numbers in the parameters have to be (IFADD, values in DUPLEX on DA checked for consistency with the components allo­ DUPLEX) converters at IFADD cated. TRANS! Transform pair .of 13 (DUPLEX, analogue values in DUPLEX INTGLH, into unpacked integers 5.2 Hybrid macros INTGRH) and store {left-hand and right-hand values). An alternative method of communication between the digital and analogue computers was required TRANSO Packing for output 15 for the dynamic region for the following reasons: (DUPLEX, (reverse of above) 1. To obtain a fast response. INTGLH, 2. The 1/0 Subroutines provided generality, INTGRH) but incurred some overhead. CLRHYD Clears hybrid interface 2 3. Programmed operators in the Monitor conditions register cannot be executed at the interrupt level. 4. A time-shared job (e.g. initial and terminal USUB Declares subroutine 2 regions) may be descheduled. (A, B) header, number A and The use of macros was also explored on the external labels B previous hybrid. lt enabled an intermediate level URET Declares subroutine 3 language to be provided, with minimum overhead return on execution time. This can readily be modified during development. For incorporation into a FORTRAN program, the macros are combined into subroutines. The macros implemented command is provided for reading or setting each initially are shown in Table 2. type of component. lt is also possible to specify Other macros to be specified will deal with the problem variable names, and the correspond­ logic and mode control. An associated subroutine ing component numbers and scale factors as is required for execution before the critical part parameters of the Interpreter. The problem may of the dynamic region to request critical operation then be checked in terms of its own nomenclature from the HYDSRN, to lock the job in core and and units. connect it to an interrupt level. Only one hybrid The Interpreter was programmed in FORTRAN job may perform critical transfers at a time and in about 3 man-mönths and has been most effective all non-critical transfers must be suspended in problem testing. whilst it is in progress. The macros have been applied satisfactorily, but it is proposed to simplify the source defini­ 6. Hybrid diagnostic tions, and possibly make them compatible with the 1/0 Subroutines. Although the dynamic region This provides an interacti ve diagnostic package is programmed with macros the core occupancy to check the performance of all analogue and is not excessive as the number of different trans­ interface components. Like the Interpreter, it is fers is small. run during time-sharing. There is a total of 22 different tests, programmed as separate FORTRAN subroutines, divided between three 5.3 Hybridinterpreter pairs of patchboards. The tests associated with each patchboard may be run in sequence or This package allows a user to issue one line com­ demanded indi vidually. mands to the system, without having to program The diagnostic was also programmed in CALL statements for the 1/0 Subroutines. Entry FORTRAN in a shorter time than the Interpreter, and execution of commands is performed without but much additional time was involved in specify­ noticeable delay during time-sharing. A different ing the diagnostic actions.

73 7. Conclusions Acknowledgements

The production of the hybrid software for a The software work described in the paper was multi-access system involved a considerable designed and implemented by the following people: amount of investigation, including research and Lynn Wiseman development, before designs could be frozen. K. McGill Hence the implementation time was extended W. Swindells beyond that for an equivalent known system. D. Utting The use of a time-sharing system has been in addition to the author. Without a major contri­ found very beneficial both for software develop­ bution from everyone in this team (and smaller ment and for problem testing. After an initial contributions from others), the system could not short period when a number of monitor crashes have been developed. were caused by hybrid development, computer­ aided design users have scarcely been affected by 1. HAMBURY, J.N., 'Programming and testing hybrid the hybrid work. The latter has been able to simulations', Computer Bulletin, Vl5, p. 300 (August proceed without severe pressure to minimise the 1971). amount of digital computer time used. Setting 2. HAMBURY, J.N., and BARNEY, G.C., 'The hybrid in potentiometers under interrupt control is quite control', AICA - IFIP Conference on Hybrid Computation, Munich (197 0). rapid and it has been possible to obtain a critical 3. PDP-10 Reference Handbook, Section 3, 'Time- sharing response without shutting down the time-sharing monitors', Digital Equipment Corporation, pp.153, 302 facility. During the development of the HYDSRN, (1969). however, the complete computer system has been 4. MIDDLETON, J.R., BARNEY, G.C., and HAMBURY, required during all major testing work. lt has J.N., 'A simulation of the LD steelmaking process using therefore been necessary to devote the computer the UMIST facilities ', UK Simulation Council Symposium to system check out for two hours every day and (January1972). occasionally for langer periods outside normal working hours. The time-sharing facility is with­ drawn from the users at these times, when soft­ Discussion ware and hardware specialists often work together. Q. How much core store did you have, how big The hybrid software is documented both for was the monitor and how much of that is locked? users and for system development. The packages have been applied to the hybrid simulation of the A. We have a 48K store of 32-bit words. The 1D Steelmaking Process [ 4] . monitor size is 20K, of which 3K is locked. These are the sizes we get without particularly trying to make it small.

74 Process scheduling by output considerations

G. McC. HAWORTH University of Cambridge, England

lntroduction The unweighted deterministic problem

In multi-tasking systems when it is not possible The cost in the deterministic cases is minimised to guarantee completion of all activities by speci­ by sequencing the Ji without pre-emption or idle­ fied times, the scheduling problem is not straight­ time [1, p. 24 l. When wi = 1, the iterative algo­ forward. Examples of this situation in real-time rithm on p. 76 computes the best sequence. This programming include the occurrence of alarm method is more convenient than the branch-and­ conditions and the buffering of output to peripher­ bound approach of [2] but springs from the same als in on-line facilities. The latter case is source, namely studied here with the hope of indicating one solu­ tion to the general problem. Th. UDl Three parameters are associated with each job max ) = J n i ,n). d l ,;;; (d2 ,P2 J 1 precedes 2 when = 2 Ji ( = 1, ... These are the processing time estimate p. , the due-date di , and a positive (Fig.1) weighting 1.-wi · Three problem areas are distin­ guished: Th. UD2 1. The unweighted deterministic case (UDP) i < j, d. ,;;; max(d.,p.) * J. precedes where pi is the known processing time and '1.- J J '1.- J.J wi = 1 for each Ji . (fo r any 'n') 2. The weighted deterministic case (WDP) where we have general weights w and i •' .. known processing times Pi. ,•' • 3. The stochastic case (SP), where the pro­ ------··•', · cessing time of Ji is a random variable with an exponential distribution and mean Pi . General weights cause no difficulty in this case, but we are particularly interested in sub-optimal schedules as the optimal schedule cannot be derived entirely in algebraic terms.

Given a schedule s, Ji will be completed at time ci (S): the cost which we seek to minimise is n Fig. 1 T = Expectation w. x max O C. (S) - d.] j � '1.- [ , '1.- '1.- l 1 i= 1 1 and jobs are indexed so that An 'eligible' job is one which is not excluded from the next position by Theorem UD2. The -1 -1 i < j * p .w . < p .w . or algorithm forms the LEJ (longest eligible job) '1.- '1.- J J sequence by executing the longest eligible job at each stage. The LEJ sequence is certainly as -1 -1 (p .w. = p .w. , d. ,;;; d .) good as the EDD (earliest due-date) and IST '1.- '1.- J J '1.- J (least slack-time) sequences, and connot be The full derivation of the algorithms, which improved by interchanging jobs adjacent in the are original, can be found in [4] . sequence.

75 Algorithm for the UDP

global proc, due, best sequence fl:n] ; comment 'proc' and 'due' hold the processing time and due dates respectively of the jobs l,•••• ,n;

{comment this block computes the best sequence [l:n] from proc, due [l:n] for the unweighted deterministic problem; � tard, done, seq [l:n] , best cost� deferred job, start of tai1, in doubt; form LEJ sequence (l,n); best sequence := seq; best cost := cost; checktail; while in doubt do {try to improve best sequence; checktail}}

form LEJ sequence (start, limit) � {comment this fills places start,••• ,n with job indices � limit; l oca l i, 1, pr, p l ace; p r := 0; if start =/- 1 then for i := 1 � start-1 do pr := pr + proc[seq[i]]; for place := start to n do -{comment this p�s the longest eligible job in place; i := l ; whi l e done [ i]> 0 do i : = i+ 1 ; 1 : = i +l ; while li"'i'TnJt and proc[l]

n cost � I: ta rd [ i] i=l

check ta i I kt {comment this looks for the shortest tail sequence that might not be in the optimal order; local place, prefer; in doubt := false; place := n; prefer := n+l; while not in doubt and place>0 do �one[seq[place]] -;-:-0; if seq[place]> prefer then - {in doubt := true; deferred job := seq[place]; start of tai� place} eise if tard[seq[place]] > proc[seq[place]] then -- - {done[seq[place]] := -1; = if seq[place] < prefer --then prefer : seq[place]} place := pT;ce - 1}}

try to improve best sequence kt {comment this defers the first job in the doubtful tail sequence; form LEJ sequence (start of tail, deferred job -1); if cost

76 6 STOCHASTIC POLICIES

3331 3333

/ 4 3332 /

1131

1111 2 2222 KEY ------OPTIMAL ...... UB-OPT. A / ------S B - - - C / VALUES P1= l pz=e P3=e2 Wi = l d3=0 0 4 6 8

U W = {i\e.(LEJ) - p. > d. , ]j > i s.t. J. the problem considerably, and no method match­ 1, 1, 1, J ing the efficiency of the UDP algorithm is possible.

precedes Ji in LEJ } One method [ 5 J has been proposed, but it is unwieldy for our purposes and has been shown to then the minimal cost is not less than be sub-optimal by a three-job case study [1, T(LEJ) - � [e. (LEJ) -p. - d.]. pp. 46-8]. iEW 1, 1, 1, Corresponding to Th. UDl, we have, when d Hence, w = t/J is a sufficient but not necessary i , d2 E;; P 1 + P2 condition for the LEJ sequence to be optimal, and it is usually satisfied. Th. WDl 1 -1 d 1 E;; max[ p 2 + ( - uJ1 uJ2 ) P 1 ' i U e .(LEJ) -p. E;; di for all , then LEJ coincid�s with Ebn and is optimal. Thus the EDD -1 d -1 ( - ) ( ) uJ l uJ2 2 + uJ l w l w2 p l + P2 ] rule, which is known to be best ü each Ji can be n ( completed by di , is seen to have far wider opti­ - J1 precedes J2 when = 2 see Figs.2, 3) mal properties. The algorithm has been run on collections of but this does not lead to the analogous form of 100 job-sets for various 'n', with Pi, di random Th.UD2. in [0, 1] and [O, ½n] respectively. For n = 4, , w = t/J 95 times (out of 100) and LEJ was sub-opt. 3 times. For n = 8, w = t/J 77 times and LEJ was sub-optimal 7 times. For n = 16, / w = t/J 28 times, LEJ was sub-optimal 26 times, run J1 run J and on average, the algorithm performed only 2 two iterations after the initial LEJ. /\

. The weighted deterministic problem

Fig. 2 The addition of general weights wi complicates

77 dz dz

preference cyclic

run J 1 run J2 N 3: V w; = l ..... 3: d3 = 0

d1 d 1

Fig. 3 Fig. 4

The current goal is to find an algorithm which The dynamic programming principle of optimal­ will reduce to the UDP algorithm of p. 76 when we ity gives the equation set the general weights to 1. In this direction we • - 1 have: - C(S ,t) = e (t) + min p. [C(S .,t) - C(S ,t) ] 8 iE S i. i. -1 where sc{ 1,.... ,n} ; s . = s - {i} ; Th. WD2 i

The stochastic problem

We add conditions of uncertainty to the problem in the most convenient way by assuming that the The result for n = 2 is processing-time of Ji is a random variable exponentially distributed with known mean pi . Th.S1 The probability of Ji terminating does not then depend on the time for which it has already run, d / d1 ,;; 2 + p 1 log w 1p2 ) /(w2p 1 ) = run J 1 and so this simplification leads to a Markov sys­ (J 1 Jz) tem . More general probability distributions and < cost functions are treated in [ 3] for the case Note that with three jobs, the situation J 1 < J2, n = 2 . J2 < J 3 and J3 < J1 may arise! (See Fig . 4.)

78 The best-decision areas for wi = 1, d 3 = o Rule B is the best for the purposes of schedul­ ing in real-time systems as it is applicable with = exp(i-1) are depicted in the graph on and pi general weights, quick to calculate and in close p. 77. lt is conjectured that the decision at time agreement with the optimal decision rule. In 3 = d3 = t ,;;;; d is the decision at t for n 3, in many applications, including the one studied in which case the graph is sufficient representation the next section, the other modelling assumptions of the solution. being made will make the difference between Since numerical techniques are involved in rule B and the optimal rule insignificant. finding the decision areas, we turn to more con­ venient sub-optimal policies for implementation.

One application: an on-line facility

The primary purpose of processor scheduling in Sub-optimal stochastic policies an on-line system is to maintain the illusion for each user that the computer is dedicated to him. The graph on p. 77 compares the optimal decision Most of the scheduling algorithms proposed and rule with three sub-optimal rules. The quartet implemented are based on resource considera­ ' ij k l' in each region means "choice ' i' with opti­ tions only such as time quanta, time already mal rule, choice 'j' with rule A, 'k' with Band spent on a process, or - if the process is not 'l' with C". represented in core - storage requirements. The illusion mentioned above will be achieved A. If we insist that when we switch from J to J j i if all output channels are kept busy, and the using this rule, J is the best choice in the proposal of this section is that we can come j absence of Ji , and vice versa, then the closer to that goal by monitoring the output per­ boundaries can be calculated algebraically. Where formance of each process. they differ from those of the optimal policy and. The on-line system modelled here is one in

those of policy B below, they are marked by which 'n' users ui at separate consoles have each dotted lines. Figure 5 indicates how the order of submitted a task J. . The number 'n' varies with i. preference of the jobs at any one time changes in time, but we make no attempt to anticipate the a simple case. arrival of new tasks: later arrivals pre-empt the currently running process if necessary. An

amount di (t) of output has been created by Ji B. With i < j, define J J as but not received by u , and this backlog, meas­ i > j i > p .• ured by the time it will take to clear, gives us a d.i. - d.J i. log e [(w.p.)/(w.p.)]-Z.J J-Z. due-date for J .• A further time d (t) may i. i z = { l i < }3 kEZ s.t. k � 'rJjEZ elapse before Ji produces more output to main­ j J.i. >J.V j j J tain the continuity of the data stream. Pi is an The decision of rule B is to run Jk , and this estimate of the time required by Ji to produce a is analogous to the LEJ sequence in the determin­ unit of output, and a variety of simple heuristics istic case. are available to decide this parameter. The weight w. might represent an amalgamation of factors iuch as the status of u i, the time C. p. + d. acts as an index when all w = 1 • already received by J and the output already - i. i. i i With rule C, we run J where k received by u .. d d i. The stocha1tic model with sub-optimal policy pk + k ,;;;; pi + i 'rJ 'B' seems appropriate given the approximations D. Also when the wi = 1, we might apply the above. Since P, �, 4. and 'n' are all functions of deterministic rule. This is not shown on the time, the algorithm must be quantised in some graph as it simply divides the area depicted way to maintain CPU utilisation and control between J 1 and J2 • housekeeping overheads.

0

3 3 k" l __.2 2 2 2 l 1------i 4 2< 3 3 3 l 2 2 ------4 4 ...... - 2 2 2 4 ....-- 1 3 3 3 l l l l l l 4 4 4 4

Fig. 5 l llustrating how the preference order can change with sub-optimal strategy A in the stochastic case. The calculations are done in backwards time.

79 Acknowledgement Discussion

I should like to thank Professor J. F. Coales and Q. Is the algorithm for the Weighted Determinist­ Dr J. D. Roberts for supporting this contribution ic Problem linear? to the Seminar, and P. Nash for the stimulus of a continuing dialogue on the ramifications of the A. No, the execution time is proportional to stochastic problem. N log N. (Similarly for the Unweighted Determi­ nistic Problem.)

1. CONWAY, R.W., MAXWELL, W.L., and MILLER, L.W., Q. What happens when a new job is added? 'Theory of scheduling', Addison-Wesley Publishing Corporation (1967). 2. EMMONS, H., 'One machine sequencing to minimise A. Its priority has to be decided, and then the certain fw1ctions of job tardiness ', Operations Research, algorithm used to determine the schedule for the Vl7, pp.701-715 (1969). new set of jobs. 3. GITTINS, J.C., 'Optimal resource allocation in chemical research ', Advances in Applied Probability, Vl, Q. How does your method compare with a pure pp. 238-270 (1969). 4. HAWORTH, G.McC., 'Tardiness scheduling and computer priority scheme? systems ', Cambridge University Engineering Department Technical Report CUED /B-Control/TR22 (1972). A. lt works as though each job has a gradually 5. SCHILD, A., and FREDMAN, I.J., 'Scheduling tasks with increasing priority. deadlines and linear lclss functions ', Management Science, V7, pp. 280-285 (1961).

80 CALAS70 -a real-time operating system based on pseudoprocessors

G.HEPKE Kernforschungszentrum Karlsruhe, W. Germany

1. lntroduction 3. Pseudo-processors as system modules

The changing prices of minicomputers mark one The elements of the system are pseudo-processors direction in which real-time systems will develop: which can be considered to be independent dedicated cheap computers will be used in a decentralised minicomputers. The operating system can be taken · manner to solve individual problems. This solu­ as a network of pseudo-processors which are tion covers quite a number of applications for coupled via common core storage; cooperation real-time systems; other applications, however, takes place through special commands. call for new central systems, to be developed Each pseudo-processor is represented by a set satisfactorily in the future. The concept and of registers, a task queue and a program with design of central systems, however, may profit variables for processing these tasks. As a rule, from the decentralised solution. The processes* each task is characterised by a small number of to be controlled and computed by the system parameters for setting the respective pseudo­ presented here are long-term scientific experi­ processor, and that means programming the pro­ ments. The creative man carrying out the experi­ gram. ments requires a high degree of convenience, and By using only one processor and a restricted that means a time-sharing system. core memory, the independent pseudo-processors become dependent on each other with respect to time. 2. Principles of system design The multiplexing of the processor as well as the adaptive processing of the queues are subjects The system design is based mainly on: of Mr Herbstreith's paper [1 l (see p. 84 of this 1. Specific requirements of experimental book). operation. 2. Advantages of decentralised systems. 4. Peripheral devices and pseudo-processors 3. Precise knowledge of the task profile. 4. Facilitation of implementation, testing, All activities of the system are integrated into and assembling of system elements. the concept of the pseudo-processors. System The specific requirements of experimental and experiment periphery are embedded in Operation include, for example, rapid data acqui­ pseudo-processors in order to be capable of sition and transfer to tape and/or disk, long-term general cooperation. Thus, the task for a peri­ data management, and programs for interactive pheral device is no langer different from tasks work with graphic displays. for other pseudo-processors; the peripheral The advantages of decentralised systems are device is directly accessible to the user who need simplicity, easy handling and programming, not tackle its specifications as check and control reliability of system software, and independence. bits. Nevertheless, he is directly connected to A well known task profile allows time and the hardware of the device, and is able to state storage saving restrictions by dedicated programs. as task parameter the interrupt subroutine pro­ The system architecture reflects the natural static grammed on its own. and dynamic modularity of the tasks of the system and thus facilitates the management of the system. 5. States of pseudo-processors and system

In order to increase the transparency and to *i.e. technical processes in this context. decrease reaction time and failure rate of the 81 Call By WAKEUP the possibly 'sleeping' initiator Wake up of the waking-up process is woken up (set 'active'). By EXIT a process comes to an end and thus Sleep the task clears the pseudo-processor. EXIT may imply an automatic SLEEP or an automatic WAKEUP. This mechanism, which is installed as a safety precaution, may block a whole line of pseudo-processors. This blocking can be avoided Pass by use of the PASS command. By PASS a process transfers a task and is brought to an end unconditionally. This is pos­ sible since the 'obligation to wake up' is transfer­ red to the new task.

7. Prevention of deadlocks

The task profile of the system allows fulfilment of all jobs by cooperation of few processes. This Fig. 1 States of the pseudo-processors is important when deadlocks are to be excluded a priori • All system resources available for the users are pseudo-processors, which, in general, system, the number of relevant states and cannot occupy each other, but cooperate with changes of states must be kept as small as pos­ equal rights in a dynamic mode through task and sible. The same is true for commands acting on receipt. Nevertheless, all conditions leading to these states. a deadlock can be satisfied [2]. However, one of The relevant states of the pseudo-processors them can be excluded a priori in this system by (see Fig. 1) are: the 'circular wait condition '. The only pre­ 1. Waiting, for activation through a task or requisite consists in checking the individual short reactivation of a task already started. task chains for loops. 2. Active, i.e., able to work or working. The relevant changes of state for the integral system are: 8. Concluding remarks 1. Upon definitive or provisional termination of a task the next active task must be The fundamental elements of CALAS70 have been searched for processing. working for more than one year. The system was 2. Upon activation and reactivation, respect­ improved steadily by extension and addition of ively, of a more urgent task than the task pseudo-processors. Major difficulties have not being processed, the more urgent task is occurred. started at once. Experience gained under the test conditions used so far - hardware simulation of experiments - has been very satisfactory. 6. Communication, control commands Further improvement now calls for measured results furnished by the real system or by simu­ The pseudo-processors are independent units lation models, so that an even better static and, executing processes of specific types defined by above all, dynamic adaptibility of the system can tasks. Since, in general, a job includes the be achieved. sequence of different processes, commands must The small number of control commands and be available for cooperation between processes system states guarantee fast changes of state, and for sequence control. good software reliability and system transparency. By CALL a process gives a task to another The given design has been described with refer­ pseudo-processor. Significant parameters of this ence to a system developed by the Institut für command are the name of the pseudo-processor Datenverarbeitung in der Technik (IDT) of the addressed and a task identification which distingui­ Kernforschungszentrum Karlsruhe. shes up to 23 tasks given by only one single pro­ The concept of pseudo-processors has stood cess. the test. By SLEEP a process changes over to a prelim­ inary state of rest ('waiting') in order to synchro­ nise with other processes initiated by it. Para­ 1. HERBSTREITH, H., 'A dynamic adaptive scheduling meters of this command are the task identifications scheme for a real-time operating system', Proceed­ of the corresponding tasks. ings of the 2nd European Seminar on Real-Time 82 Programming - Computing with Real-Time Systems, A. No, there is only one waiting state. Vol. 2 (this issue), p.84 , Erlangen (March 1972). 2. COFFMAN, E. G., et al., 'System deadlocks'. Compu­ Q. Are pseudo-processors real machines? ting Surveys, V3(2), (June 1971). 3. HERBSTREITH, H., and HEPKE, G., 'Ablaufsteuerung fÜr ein System mit einfacher Hardware struktur', A. No, they are virtual machines. KFK-Bericht 1530, Gesellschaft für Kernforschung Karlsruhe (1971). Q. What 'safety precautions' are there?

A. A pseudo-processor must wait until all its Discussion subtasks are finished. Each created task does its own book-keeping. Q. When a job is waiting it can be awakened by a REPLY from a subtask or by a CALL from the Q. Which computer is this implemented on? Scheduler. Does it follow from this that there are two waiting states? A. Telefunken TR86 with 64K words of store, in which this software takes lOK.

83 A dynamic adaptive scheduling scheme for a real-time operating system

H. HERBSTREITH Kernforschungszentrum Karlsruhe, W. Germany

1. lntroduction number. The real processor is allocated accord­ ing to a second number, the priority number. This paper is intended to extend and complement The distribution of the düferent tasks among the the paper by G. Hepke [ 3]. lt describes some pseudo-processors of classes (1), (3) and (4) fol­ design criteria and the realisation of adaptive lows a fixed scheme, depending on the configura­ scheduling strategies in the multiprogramming tion. As will be pointed out below, certain real-time system CALAS70. At an early stage in system functions require two pseudo-processors the design of the system [ 2 l we noticed that com­ with unequal priorities. Pseudo-processors of mon strategies could not be realised in the same class (2) are allocated dynamically by the way as in an interactive time-sharing system [1 l. scheduler. The non-time-critical background The reason was that the term response time in tasks are performed by only one special pseudo­ process control systems generally has another processor, which executes the requesting pro­ meaning from that in other systems. This forces cesses on a round-robin basis with iixed time the designer to over-design the system capacity, slices. to avoid process failure as a result of bad observ­ ance of the required response times. On the other hand, one has to compromise for an optimal 3. Scheduling strategies utilisation of the unused system capacities with regard to changing load distribution as encountered For the description of the implemented scheduling in laboratory automation work. The effect of the concept, it seems convenient to use the distinction so-called background tasks on real-time require­ between two main levels of scheduling, the short­ ments was eliminated by the strategies to be term and the medium-term scheduling, made by described below. As far as scheduling is concer­ Saltzer [ 5]. Only short-term strategies are con­ ned, a further requirement is the realisation of sidered here. response tim es of the order 300- 500 µsec.

Short-term scheduling 2. System concept At this lower level of scheduling (also called hard­ The internal system structure is based on ware management) the tasks to perform are: Dijkstra's concept of "Hierarchical Ordering of a. Allocation of a pseudo-processor to each Sequential Processes" [4]. lt consists of a fixed sequential process. number of pseudo-processors, created during b. Management of changes of state of the system generation. These processors execute pseudo-processors. the sequential processes. lt is possible to differ­ c. Making available a set of primitive basis entiate between four classes of pseudo-processes, functions for communication between pro­ according to their responsibilities for the follow­ cesses. ing tasks: The allocation of the real processor, according 1. System services (e.g. I/0 functions, main to the ready list of pseudo-processors, is managed storage management, timer, statistics, by the dispatcher. The ready list has a two­ etc.). dimensional organisation and makes the selection 2. Real-time tasks. of highest priority processes as fast as possible. 3. Man-machine communication. One dimension, the vertical, represents the 4. Non-time-critical background work. pseudo-processors. In the horizontal dimension Each pseudo-processor is identified by its ID- the ready processes are queued with respect to

84 - _ _ - r_ _ - _ _ _ _ _....., �:�:;,:Y p 1 �r---pse_udop ocessor l rud

1 l

class 2 priority _l'.l pseudoprocessor n

class l pseudoprocessor m Processes priority p2 in queues

class 3 pse�doprocessor 0 priori ty P3

class 4 priority P4 pseudoprocessor 99 pseudoprocessor 100

Fig. 1 Ready I ist of pseudo-processors

their priorities. These two degrees of freedom for scheduling allow a reasonable distribution of system capacities among the different tasks 8 ( - Fig.1). - ----.1� 1 1

Process queuing (Fig.2)

On creation of a process, the priority of that pseudo-processor which creates the process is assigned to it. The process will then be inserted in the corresponding queue of its pseudo-processor. The insertion is performed, according to the pri­ ority, and the look-up is started at the tail of the queue, with the restriction that a possibly already­ active process at the head of this queue will not be moved by the insertion. By this method the processes with the highest priorities are always Fig. 2 Assignment of priorities to system processes

85 at the head of the queue and are therefore executed first. Thus, processes generated from classes (3) and (4) (Section 2) do not disturb the time pl sequence of processes generated from the real­ time class (2). To accomplish fast response times of the sys­ P2 - tem, the scheduling functions have to be executed 1 1 1 as fast as possible, since the real processor 1 1 1 1 E'.1 P4 cannot be interrupted during the execution. As an example, we note that the necessary processor p2 1 time for the insertion of a new member into a 1 1 EJ queue increases with the length of the queue. Assuming that, on an average, ten members will EJ ' 1 1 have to be checked, this time should not exceed 1 1 e-1 P4 P4 r--, r=-, 300-500 µsec. This assumption is sufficient, and P4 1 so the length of all queues connected to class (1) will be reduced in the following way: a. If the length of the queue exceeds 15, all processes generated by classes (3) and (4) Fig. 3 Allocati an of pseudo-processors p2 to system processes are rejected. b. If the length still exceeds a value of 20, the lowest priorities of the real-time class are rejected too. 4. Conclusion

Assignment of pseudo-processors to system service processes By the use of these three scheduling strategies we have been able to develop standard solutions for As already mentioned, there are two pseudo­ the design of a real-time scheduler. We have processors available for each of some special shown the possibility of isolating real-time work dedicated system service functions of class (1). from background tasks with a parallel decrease The corresponding processes in the queues are in response time. lt is our belief that the methods assigned dynamically to either one or the other discussed here improve the design of central pseudo-processors, depending on the priority of multi-access systems in process control and these processes. If _!lk (with k = 2, 3, 4) are the laboratory automation. Our concept allows for the priorities of classes K respectively, and p1 , p2 introduction of additional background work into the priorities of the special pseudo-processors the system, without deterioration of real-time of class (1), then (Fig. 3) requirements.

P1 > _!l2 > P2 > _!)3 > _!)4 1. CHAMBERLIN, D., 'Comparative modelling of time­ slicing and deadline scheduling for interactive systems', The pseudo-processor with priority p2 is always executing processes as lang as there are no pro­ RC 3378 (15410), Research Report of the IBM Thomas Watson Research Center, Yorktown Heights, New cesses generated from class (2). On creation of York 10598 (25 May 1971). processes of class (2), the pseudo-processor with 2. GAGEL, G., HEPKE, G., HERBSTREITH, H., and priority l, will be switched on until all these NEHMER, J., 'CALAS68 - ein computergestütztes P real-time tasks have been executed. Vielfachzugriffssystem zur Laborautomatisierung', Three essential actions are required by the Ext. Bericht Nr. 19 /69-1 der Gesellschaft für processor switching: Kernforschung Karlsruhe (November 1970). 3. HEPKE, G., 'CALAS70 - a real-time operating system a. The last active processor is removed from based on pseudo-processors', Proceedings of the 2nd ready list and becomes invisible for the European Seminar on Real-Time Programming - dispatcher. Computing with Real-Time Systems, Vol. 2 (this b. The status of the now blocked processor is issue), p. 81 , Erlangen (March 1972). copied into the register field of the other 4. DIJKSTRA, E. W ., 'Hierarchical ordering of sequential processes', Intern. Seminar on Operating processor. System Techn., Belfast (August 1971). c. The new processor to activate is entered 5. SALTZER, J. H., 'Traffic control in a multiplexed into the ready list and the corresponding compiler system', MAC-TR-30, MIT, Cambridge process queue is assigned to it. (July 1966).

86 Workshop on components of real-time systems

Chairman: Prof. Dr R. BAUMAN Munich, W. Germa ny

Discussion was concerned with the use of priori­ Working space allocation ties for controlling the task scheduling and work­ ing space allocation (how dynamic it has to be). S. In relation to Dr Pyle's paper I understand lt was generally agreed that a real-time system that what he is proposing with regard to store differed from a general time-sharing system in allocation is as follows: store is allocated in a the attitude of the users: static manner at load time for each process but can be allocated dynamically within a process. J. Oursis not a time-sharing system in which users may be trying to break the system. We can Q. What is 'load time' in a real-time system? assume they are cooperating on the solution of a problem. A. When you first set the program up to run. M. The choice of storage allocation mechanism Priority structures depends very much on the type of application. The term 'real-time' is used to cover a multitude L. There is a golden rule: the priority of a pro­ of sins from a simple data gathering system cess varies inversely as the critical response which has fixed storage requirements but time for that process. Demands for very short relatively fast response times, to an Airline response time may call for activation of lower reservation system which needs sophisticated priority processes. As an example, a block of algorithms for storage but not particularly disk transfers generates demands on at least 3 demanding response times . levels of priority: 1. The demand for individual ward transfer. Y. Cases can be made for dynamic storage allo­ 2. The interrupt to identify the end of the cation, for example a free store area containing block. a pool of blocks of fixed size (the size agreed 3. The scheduling of the process which will between the designers of the processes using this use the information. pool) . However, even with this in a system, the The level of priority decreases from 1 to 3. whole store is partitioned in a fixed way at load time between those areas used for program G. Hardware interrupts are handled at the storage, those used for genuine static storage priority needed to deal with the necessary immedi­ and those used for stacks or buffer pools. The ate action only. A software interrupt is then management of the areas within which storage is scheduled at a lower priority to deal with the less used dynamically is done by a higher level pro­ urgent part of the action. In general the higher gram at a level of sophistication above that of the priorities are used for the minimum of time to primitives given. handle the most urgent part of a response, the rest of the processing being scheduled at a lower P. Dynamic allocation of working space (admini­ priority. stered by the operating system) can give efficient use of store and easier implementation of re­ J. Is it not true that the author of a task is the entrant tasks. At RREwe implemented message best one to assign its priority, since he knows passing in an operating system. The mechanism how important his job is. (This is not a time­ provides message communication between parallel sharing system for user-programmers.) We processes, which simplifies the problems of con­ insist that programs suspend themselves regularly trolling program interactions. We found that the stating their own priority, e.g. low, high, resume timing overheads in acquiring free areas and after 5 secs. sending them to other processes were rather high.

87 We are now in the process of implementing a taining an 'attempt to secure' primitive) , with hardware version of this system. The hardware, the situation when that time cannot be determined which will be a computer peripheral, will enable even to that extent, and is essentially unbounded us to acquire free area and send messages to (e.g. a program containing a 'secure' primitive, other processes in time of order 100 nsecs. or a program in an environment using dynamic storage allocation where there is the possibility Y. We may contrast the situation when the time that store required may not be immediately avail­ a piece of program will take to execute can be able) . determined, perhaps as a conditional expression I regard the former situation , of conditionally involving conditions not removable in advance determinable andbou nded time, as acceptable for (e.g. a program containing a test on character real-time systems, and the latter, of unpredict­ read in and appropriate action , or a program con- able unbounded time, as not acceptable.

88 SPECIAL SYSTEMS AND SYSTEM FEATURES

Chairman: Dr H-J. TREBST

89

Simulation du deroulement logique de programmes de commande de spectrometres a neutrons

Ph. BLANCHARD, Ph. LEDEBT and M. TAESCHNER Institut Laue-Langevin, Grenoble, France

1 - Generalites - lntroduction Description du Systeme Carine

Ce systeme de simulation est supporte par un Chaque calculateur de processus gere six spectro­ terminal 27 41, connect� sur le mat�riel metres par l 'intermediaire de programmes IBM 360/67 de !'Institut de Mathematiques Appli­ FORTRAN temps reel. Une bibliotheque de sous­ quees de l'Universite de Grenoble. Ce calculateur programmes assembleurs, gere les entrees/sor­ fonctionne en time-sharing, avec le systeme ties, et chaque sous-programme peut etre appele CP /CMS, base sur l 'utilisation des machines par le FORTRAN. Chaque utilisateur dispose virtuelles en mode conversationnel. Chaque utili­ aupres de son experience, d'un teletype pour sateur a donc a sa disposition, un calculateur demarrer, contröler, arreter ses programmes virtuel, type 360/40 avec imprimante virtuelle et suivre ainsi l'evolution de sa manipulation. lecteur cartes/perfo cartes virtuel, etc. Les transferts d'information calculateur­ Nous allons regarder maintenant le systeme experience et vice versa, sont assures par l 'inter­ reel de gestion des experiences. mediaire d'un standard electronique, le CAMAC.

X Progra111ne d'experi ence

-----� X ---t-----t--

X

l- niveau

er l niv eau Interface = x Calculateu r -- Experi ence

Diapositive 1 Diagramme general

91 CMS

11 existe une quarantaine de requetes dans 1 'envi­ ronnement

EDIT

QJ ...., :, Q_ Simulation C: QJ C: �,0, Notre but etait de fournir a l 'utilisateur un outil !\ lui permettant de creer et mettre au point ses programmes d'experiences, sans le secours des calculateurs de processus, afin de soulager le background de ces systemes. Afin de garder toute son efficacite, le systeme de simulation garde la meme structure de dialogue, et de INPUT possibilites que le systeme reel. Pour conserver cette structure, nous avons utilise le macro langage de commande CMS (Cambridge Monotor System), qui permet de remplacer les series d'ordre par une seule commande EXEC avec parametres. Nous allons maintenant regarder ce qu'est le systeme CP /CMS. Diapositive 2 Systeme CP/CMS

11 - Systeme CP/CMS donc une machine virtuelle generee par CP /67. CP: Le systeme generateur de machines virtu­ L'avantage de cette solution est de mettre a dis­ elles CP 67 a ete corn;u et developpe par le position d 'un utilisateur les vastes possibilites Centre Scientifique IBM de cambridge en collabor­ d'un gros calculateur: grande memoire, unites ation avec le Lincoln Laboratory du M.I.T. La d'entree sortie rapide, puissance de calcul, etc. version initiale a ete mise en Service en A vril Immediatement apres initialisation, la 1968. CP 67 permet de faire fonctionner sur un machine CMS atteint un etat stable particulier, 360/67 un nombre quelconque de machines virtu­ appele 'attente de commandes'. Les commandes elles qui sont des 360 standards. La memoire disponibles appartiennent a deux familles: centrale de cette machine virtuelle peut etre plus 1. Celles dont l 'execution provoque un change­ grande que celle du 360/67 utilise. L'activation ment d 'etat. d 'une machine virtuelle se fait a partir d'une 2. Celles qui apres execution impliquent un console terminale connectee au 360/67 grä.ce a retour immediat a l 'etat stable de base. son nom et son mot de passe. Une fois 1a Differents etats stables permettent d'entrer des machine activee, un systeme de programmation fichiers, de corriger des fichiers, d 'executer est charge en memoire virtuelle par utilisation des programmes EDIT - INPUT - A TTENTE DE du bouton (simule) 'chargement'. A partir de ce COMMANDES. moment, l'utilisateur dialogue directement avec Chaque commande rencontree est consideree le systeme qu'il vient de charger. Dans le cas comme phase elementaire, d'un langage particu­ qui nous concerne, nous chargeons un systeme lier et est executee immediatement. L 'idee de CMS, mais d'autres systemes sont disponibles. pouvoir conserver (donc de reutiliser) un groupe (APL - OS - etc.). de commandes en lui donnant un nom collectif vient naturellement a l 'esprit. On a donc un CMS: Cambridge Moniteur System). Le systeme fichier de commandes et il suffit alors de frapper CMS donne a l'utilisateur la possibilite d'employer, EXEC < nom de fichier > pour que le systeme aille en mode conversationnel un ordinateur 1MB 360, automatiquement lire ce fichier, et en interpreter

92 le contenu. C'est cette possibilite que nous avons utilisee pour la simulation, afin de conserver le ----"LOGIN EX PER" meme dialogue que sur les calculateurs de pro­ cessus. Le langage utilise est un macro langage (/) ::ia:: r u 0 de commandes CMS. EXEC est donc une com­ G) D C mande de CMS permettant l 'execution de la -< sequence de commandes contenue dans le fichier portant le nom de cette macro-commande.

111 - SIMUL

Le systeme comprend Trois parties essentielles: 1. Identification de l 'utilisateur. 2. Analyses des commandes. 3. Execution des commandes. L 'identification utilisateur comprend l 'appel du systeme SIMUL sous CMS, puis la reconnaissance de l 'utilisateur (par son nom d'experience). Ensuite ou execute la concatenation des biblio­ theques necessaires, bibliotheques systeme et utilisateurs. L'analyse des commandes, dirige vers les options Background-Foreground, (comme sur les calculateurs de processus) puis analyses les requetes de l'utilisateur, et prepare le travail (creations de fichiers intermediaires, appel de 11 11 programmes, etc ...), avant de donner la place a G0 l 'execution. "DISPLAY" L'execution correspond au travail proprement "HARDWARE" "FICH IERS" dit, et peut aussi se decomposer en trois parties: "BLOCS DE DONNEES" 1. Executions d'ordres systemes (CMS). 2. Executions de programmes FORTRAN sys­ Diapositive 3 Organigrame des environnements du systeme SIMUL teme. 3. Executions de simulation experience. La partie BACKGROUND permet 1a creation et la A tout moment, l'utilisateur peut, par la correction de programmes FORTRAN utilisateur, frappe de 1a commande 'HELP ', demander les mais ne permet pas l 'execution, les modules explications necessaires ä. chaque commande. temps reels etant seulement disponibles en execu­ De meme a tout moment l 'utilisateur peut tion dans 1a partie FOREGROUND. sortir de SIMUL par la commande OUT. Il est Dans l 'environnement Background, les opera­ necessaire d 'utiliser OUT, si l'on veut obtenir tions suivantes sont disponibles: une bonne gestion des fichiers. 1. Creation d'un programme ou sous-program- me FORTRAN...... (EPC) 2. Correction d'un programme ou sous- Les bibliotheques: programme FORTRAN...... (CPG) 3. Liste d'un programme FORTRAN ... (SPC) Le syst�me SIMUL g�re un certain nombre de 4. Liste d'un sous-programme bibliotheque: FORTRAN...... (SSC) 1. Bibliotheques utilisateurs. 5. Compilation et generation d'un 2. Bibliotheques systemes. module ...... (COP) Dans les bibliotheques utilisateurs on com­ 6. Compilation sous-programme ...... (COS) prend: 7. Lecture programme sur ruban ..... (EPR) 1. La bibliotheque de sous-programmes. 8. Lecture sous programme sur ruban . (SSR) 2. La bibliotheque de programmes. 9. Transfert dans l'environnement directement liees aux problemes utilisateurs. Foreground ...... (EFG) Ces bibliotheques sont extensibles, et compres­ Dans l 'environnement Foreground, l 'utilisateur a. sibles. acces a certaines commandes. Certaines autres Les bibliotheques systemes comprennent: commandes dependent de la commande preclldente 1. La bibliotheque standard FORTRAN. exemple: on ne peut arreter un programme 2. La bibliotheque Temps Reel. FORTRAN s'il n'a pas ete demarre. 3. Les programmes systemes.

93 PROGRAMME UTI LI SATE UR

LECTN Pl1)S2

POSAC

POSN ------ACQ - --- INIT ------TABLE ' -- ' ' LECTl ' ' CALL LECT 1 (IC0DE,VAL,IER} ,---- !CODE - Donne par. 1 'utilisateur CAMAC VAL -va 1 eur correspondante !ER - Code retour: 0 bon 1 erreur LECT 1 Diapositive 4 Modules Organigramme -1 erreur CAMAC

NON La bibliotheque temps reel, est celle qui represente en fait, le coeur de la simulation. C'est a travers ces sous-programmes que l 'utilisateur peut avoir acces a son electronique, donc a son e:xperience. KTRAV= 0 Le module de base est le module CAMAC, MESSAGE c 'est lui qui simule l 'interface de transfert, tous ERREUR les autres modules feront appel a lui, lorsqu'ils voudront communiquer avec l'e:xperience. IEX=TABLE Le standard CAMAC consiste en une gestion du transfert d'information bidirectionnelle. Chaque module hardware CAMAC est repere par CALL CAMAC une adresse (exemple COUNTER adresse BAC 1 - MODULE 15 SOUS-ADRESSE 2), pour eviter d'indiquer � chaque fois ce genre d'adresse, NON chaque variable physique CAMAC est repere dans le FORTRAN par un !CODE (entier), utilise par le module CAMAC pour rechercher la reelle adresse. Nous avons d�fini 3 sortes d'action au nivau du VAL=VAL-DECAL module CAMAC: 1. Lecture d 'information. 2. Ecriture d'information. =O 3. Fonctions speciales telles que RAZ IER echelles; initialisations, etc. Exemple d 'appel du module CAMAC:

CALL CAMAC (!CODE, KTRAV, IEX, VAL, IER). Diapositive 5 Exemple de module LECT 1 94 !CODE est lie directement � la simulatio:Q, c 'est POS1 - POS2 - POSN qui font appel a LECT1 - lui qui fournira ou recevra l 'information VAL. LECTN Dans le fonctionnement reel, ce sera le hardware lui-meme qui fournira 1a valeur. 1V - Conclusion

KTRA V indique 1a fonction: lecture, ecriture Ce systeme de simulation fonctionne depuis le speciale. mois de Juin 1971 a l 'institut Max von Laue-Paul IEX est l 'adresse du module hardware con­ Langevin de Grenoble, en donnantentiere satis­ cerne. faction. VAL information a transmettre. Nous avons pu constater, que la facilite de IER code retour d'erreur O ----->bon mise en bibliotheque de sous-programmes parti­ 1 ----->mauvais culiers, permettait une evolution constante du systeme en fonction des realisation hardware. De plus, ce systeme libere les calculateurs de processus de täches importantes telles que Les modules de plus haut niveau se composent de: edition, correction de programmes FORTRAN, en les transportant sur IBM 360/67 de fonctionne­ LECT 1 - LECTN ment plus souple, et aux plus larges possibilit�s.

95 An implementation of a virtual CAMAC processor

A. LANGSFORD AERE Harwe/1, England

1. lntroduction CAMAC sub-system Computer sub-system The impetus to design and build a 'virtual CAMAC processor' came from experience in using Memory CAMAC in a multi-user, multi-programming environment, gathering data for nuclear physics experiments [1]. Two factors were major influ­ ences in the design: CAMAC 1. Programs tend to have a short life-time in processor 1-.!...s--.1 this environment. As the needs of each experiment changed, it was found necessary CAMAC dataway to recode programs. This meant that not only high-level (FORTRAN) source code changed but also the individual CAMAC modules Computer peripherals operations. Changing the high-level code is relatively easy, but manipulating bit patterns representing CAMAC commands was, by contrast, difficult and more prone Fig. 1 Schematic diagram of CAMAC and CPU as a dual processor system to programmer error. 2. To speed data gathering, autonomous trans­ fer of data between CAMAC modules and base addresses of these two segments are passed computer memory was implemented, the to the CAMAC processor whenever a sequence of program controlling these transfers being CAMAC operations is called, the addresses being hardware encoded within CAMAC. held in a Program Segment Register and Data Recognising that CAMAC had considerable pro­ cessing power independent of the Central Proces­ Segment Register, respecti vely. In the present sor Unit, it was a reasonable step to suppose implementation each segment has a directly that the CAMAC controller and the main processor addressable length of 256 words. could form a dual processor system, each The processor has, in addition, three active accessing a common memory for their instruct­ registers: ions (see Fig. 1). P the program counter (8-bit) Rather than build such a processor in hardware at the outset, it was decided to build a 'virtual Q the CAMAC condition register (1-bit) processor' [ 2]. A simple hardware interface X an index register (8-bits) between computer and CAMAC dataway was sup­ plemented by a software driver which interprets A two-address structure has been chosen, the sequences of instructions placed in memory as form of the instruction word being shown in Fig. 2. CAMAC sub-routines. This approach has the Because the CAMAC processor has been imple­ advantage that, if the instruction set and address­ mented on a 16-bit word length central processor, ing technique chosen for the virtual processor is it was found convenient for the CAMAC instruction found unsuitable, it can be readily altered. to occupy two central processor words, i.e. 32- bits. The simplest type of instruction provides a direct transfer of data between a CAMAC module 2. Processor structure (addressed by crate, C, Module, N, and Sub­ address, A) and a location in the data segment, The processor is designed to obtain its instruct­ given by the displacement address D. All 32 ions from a read-only program segment. Data is CAMAC functions are implemented in this way, held in a read-write permitted data segment. The thougb half of them do not require a data address-

96 F C C N A M jxoj D 1 1 1 ILI +cl 1 1 1 1 1 1 1 1 1 1

F function code N module L length bit A sub-address CM CAMAC address mode M displacement address mode CAMAC index bit Xo displacement index bit Xe D C crate displacement field

Fig. 2 The CAMAC processor instruction word A number of address modes have been imple­ mented. These provide for: 1. Direct CAMAC addressing. Main 2. lndirect CAMAC addressing, the direct Program address being found in the data segment. 3. Direct data segment addressing. 4. lndirect data segment addressing with pre­ CALL CAMACt-----, indexing. 5. lndirect data segment addressing with post­ Enter LINK indexing. ( conta ins -----� enter workspace) OLERT 6. Direct program segment addressing.

fetch instruction increment P

execute i nstruction return NO struc- >---.... tion L-----

3. Processor implementation

The virtual processor has been written in about 300 instructions of re-entrant code to operate on a Honeywell DDP-516 computer working under the real-time executive OLERT. lt runs at the priority level of the calling progr�m which holds Continue its own set of CAMAC registers. In this way Main higher priority processes may interrupt the Program operation of the CAMAC processor, the context of the interrupt process being automatically pre­

Fig. 3 Flow chart showing access to CAMAC interpreter served. lt is necessary to inhibit processor inter­ rupts only for short periods. These are essen­ tially during the sequence of operations to transfer part being data-less transfers. However, CAMAC data over the CAMAC data-way, when the data-less functions 8, test-look-at-me, and 27, operations - test-status, which affect the condition register, Q, have an address part. The contents of the set up command word: transmit data: test Q specified address are set logical 'true' or 'false' depending upon whether Q is 'set' or 'cleared'. - must be treated as an indivisible instruction. There are in addition 'non-CAMAC' operations The user program accesses the virtual proces­ whieh permit operations on the X and P registers. sor through the FORTRAN call statement: The latter provide branch unconditional and branch conditional on the value of Q. There is a CALL CAMAC (data segment, program return instruction which provides an exit from the segment name) CAMAC segment. Any instruction which cannot be decoded is treated as a return. or its assembly language equivalent. 97 The data segment is an integer array declared to achieve this, for demonstration purposes the in a DIMENSION statement. The program segment present implementation has to be made compatible can either be an internally named array or an with the structure of OLERT, the environment in external subroutine name. The sequence of opera­ which the code will be executed. tions carried out in accessing, running and return lt is the author's belief that, by making it more from the virtual processor is shown in Fig. 3. lt easy to program CAMAC operations, especially will be seen that entry to the executive is through in a real-time environment, a better understand­ a link which holds workspace and the registers P, ing of the structure of CAMAC programs will X and Q peculiar to the calling program. emerge. This will, in turn, be reflected in the improved definition of CAMAC statements in high­ level languages. Moreover, defining a range of 4. Possible processor extensions processors, real or virtual, on which CAMAC statements are to be executed provides ready The author is aware that there are alternative implementations f or the high-level language state­ approaches to the design of a CAMAC processor, ments. real or virtual, and that many of the features of the present design result from the environment in which it has been implemented. With increasing 1. LANGSFORD, A., JARVIS, O.N.' and wmTEHEAD, c., 'DAMUSC - a direct access, multi-user, synchrocyclo­ experience and the freedom to manipulate the tron computer', AERE R. 6832. design of the processor, it is hoped that improve­ 2. LANGSFORD, A., 'An implementation of a virtual ments will follow and omissions be remedied. CAMAC processor and its assembly language', AERE Already certain desirable operations can be seen. R. 6914. lt would be useful to have a conditional brauch instruction, where the condition was set by the pattern of data transferred between store and Discussion CAMAC data-way. A far more significant omis­ sion, and one which the author intends to remedy Q. What is the speed of the hardware in your sys­ soon, is the lack of real-time features. Because tem? CAMAC provides for autonomous data transfer and interrupts, the virtual processor needs addi­ A. The computer itself is a microsecond machine, tional instructions so that parallel processing can but the interpretation is appreciably slower than be accomplished. To do this satisfactorily this: not fast enough for high speed CAMAC requires information from the user program to operations. identify a point in his program whose execution can be scheduled when both the current CPU pro­ Q. What is the size of your interpreter? cess and the parallel CAMAC process have termi­ nated. While the author knows, in principle, how A. About 300 instructions.

98 An implementation of the assembly language and program assembler for a virtual CAMAC processor

V.J. HOWARD A ER E Harwel/, England

1. lntroduction be link-loaded with modules coded either in the assembly language of the host computer or in any Langsford [1, 2] has described a possible imple­ high-level language implemented on that machine. mentation of a virtual CAMAC processor. This The program assembler is modular in structure processor possesses its own repertoire of and is so organised that the CAMAC processor instructions and a set of virtual registers which instruction word format and the output format of enable it to execute sequences of instructions the virtual object code can be readily altered to placed in the core store of the host computer. suit the computer system in which the virtual The instructions are stored in a read only block CAMAC processor resides. termed the 1/0 or program segment and the data for the program is transferred to and from a read/write area of store called the data segment. 2. The CAMAC assembly language The virtual CAMAC processor shares store access with the CPU (central processing unit) of The assembly language for the virtual CAMAC the host computer and will execute CAMAC processor is of conventional form for a two­ instructions concurrently with CPU activity. address machine. The language provides a symbol To assist the user to program the virtual for every legal function that the virtual processor CAMAC processor and to plant 1/0 segments can carry out and will detect and flag invalid within the computer store a symbolic assembly instructions at load-time. lt also supports language has been developed and a two-pass pro­ sym bolic descriptions of addressing modes and of gram assembler has been implemented. In form, locations within the 1/0 and data segments and it the assembly language reflects the facilities defines the format of statements for input to the offered by the CAMAC processor. lt supports CAMAC program assembler. symbolic addressing of individual CAMAC modules, data segment locations and locations within the 1/0 segment and it also provides facili­ 2. 1 Statement layout ties for extending the set of instructions recogni­ sed by the program assembler should this be An assembly language statement is divided into necessary as the virtual processor evolves. five fields, laid out as shown below: For ease of implementation the program assembler was written in PL/1 for use on an Location: function, CAMAC address, IBM 370/165 computer. lt will assemble pro­ store address, comments; grams coded in CAMAC assembly language and produces a block of object code in a form suitable For all instructions the 'location' and 'comments' for loading into the store of the host computer fields are optional. For certain instructions only using the standard loader program for CPU one of the two address fields need be specified. instructions and data. This technique .has certain advantages in that any 1/0 segment for the CAMAC processor is relocatable within the store 2.2 The function fie/d of the host computer and can be shared by a num­ ber of programs. lt also allows the 1/0 segment The function field specifies either the function or to be called at run time and permits it to be operation to be carried out by the virtual CAMAC treated as a separate program module which can processor or one of a set of pseudo-operations

99 TABLE l Non-CAMAC Operations Operations on the X register LOAD X Load X-register with contents of location in store address field. STORE X Store X-register in location specified in the store address field. SWAP X Interchange contents of the X-register and the location specified in the store address field. INCR X Add l to the X-register� Compare X-register with contents of the location in the store address field. If they are equal skip the next instruction. Operations on the P register JUMP Jump to I/0 segment location specified in the store address field. QSET Jump to the I/0 segment location specified in the store address field if the Q-register is set to 1. QNOT Jump to the I/0 segment location specified in the store address field if the Q-register is set to 0. Addressless instructions HALT Terminate execution of the I/0 segment. used to control the program assembler and to (f2 = 0), the virtual CAMAC processor matches associate symbols with data and 1/0 segment the low order bits of the CAMAC highway to the locations. The operations available to the pro­ natural word length of the computer. For CAMAC cessor and their symbolic names are summarised length, i.e. multiple length transfers (f2 = 1), the in Tables 1 and 2. The functions in Table 1 are low order of the data highway are treated as for non-CAMAC functions. They require no CAMAC single length transfers and the high order bits are address field and operate on the P, X and Q regi­ stacked in successive computer words. The sters of the virtual CAMAC processor. The HALT DE FINE DOUBLE pseudo-operation provides instruction uses no address fields at all. When facilities for reserving storage for multiple encountered at run time it terminates execution length transfers. of the CAMAC program. 0f the 32 valid CAMAC functions listed in Table 2 only the 16 standard functions have been 2.3 The store-address field assigned symbolic names. However, to facilitate the use of all 32 CAMAC function codes and to 2.3. 1 Addressing within the / /0 segment provide for the addition of new instructions indivi- · dual operation codes can be specified numerically Locations within the 1/0 segment are referenced in the function field as (fl, f2). Field f1 is a by jump instructions and when the address field 6-bit function code which defines either a CAMAC specifies a constant which is defined explicitly or or non-CAMAC operation depending upon whether symbolically within the 1/0 segment. Literals the most significant bit is O or 1. The remaining are defined explicitly by an 'equals' symbol fol­ five bits specify either the CAMAC function code lowed by an optionally signed constant, or the non-CAMAC operation. Field f2 is a single bit field which defines the length of the data eg LOADX , = Sf/Jf/J ; transfer in a CAMAC read or write operation. The prefix 'D' on READ-group or WRITE-group They can also be defined symbolically by the instruction mnemonics fulfils a similar function. DEFINE LITERAL pseudo-operation, The idea of multiple length transfers is introduced to overcome the problem of carrying out transfers eg LITNAME: DEF INE LITERAL , 500 ; when the computer word length is less than 24 bits, the length of the CAMAC data highway. For Any reference to LITNAM would produce a refer­ a machine length, i.e. single length transfer ence to a location in the 1/0 segment initialised

100 TABLE 2 CAMAC operations and their symbolic names Function number Name Type Comments * 0 READ Read Group 1 Register 1 READ 2 Read Group 2 Register 2 READCL Read and Clear Group 1 Register 3 READCMP Read group Read Complement of Group 1 Register 4 Non-Standard 5 Reserved 6 Non-Standard 7 Reserved 8 TESTLAM Test look at me r 9 CLEAR Clear Group l Register 10 CLEARLAM Dataless transfers Clear look at me 11 CLEAR 2 Clear Group 2 Register 12 Non-Standard 13 Reserved 14 Non-Standard 15 Reserved * 16 WRITE Overwrite Group 1 register 17 WRIJE 2 Overwrite Group 2 register 18 SWRITE Write group Selectively Overwrite Group 1 register 19 SWRITE 2 Selectively Overwrite Group 2 register 20 Non-Standard 21 Reserved 22 Non-Standard 23 Reserved 24 DISABLE Disable 25 INCREMENT Increment 26 ENABLE Enable 27 TESTSTATUS Dataless transfers Test Status r 28 Non-Standard 29 Reserved 30 Non-Standard 31 Reserved r Dataless transfers, except TESTCAM and TESTSTATUS, use only the CAMAC address field. For TESTLAM and TESTSTATUS instructions the value of the Q-register is loaded into the location specified in the store address field. * READ and WRITE group instructions require both CAMAC and store address fields. Such instructions, prefixed by D, imply double length transfers.

to 500. Indirect addressing is not permitted in the 1/0 Addresses referenced within the 1/0 segment segment within the present implementation. can be modified by placing (1) at the end of the store address field, 2.3.2 Addressing within the data segment eg JUMP , IOSYMBOL (1) ; This represents the most common form of Thus, in the above example, control would jump addressing and a number of options are provided. to the location within the 1/0 segment whose The basic form is a direct reference to some address is that of I0SYMB0L plus the contents of location within the data segment. This mode can the X-register. be specified either by inserting the address of the

l 01 location in numeric form within the store address 2.4 The CAMAC address field field or by using a symbolic address defined by a DEFINE DATA or DEFINE DOUBLE pseudo­ A CAMAC address can be defined explicitly by operation at some other point within the program, placing the CNA address of the module as a three integers, enclosed in parentheses, in the CAMAC address field or by referencing a symbolic eg address defined at some other stage of the pro­ SlOREX , DATA SYMBOL; gram by a DEFINE CAMAC pseudo-operation,

DATA SYMBOL: DEFINE DATA, ( ); eg n, a) As with 1/0 segment addresses, direct references CLEAR, (C , to data segment addresses can be modified by or CLEAR ' COUNTER ; placing (1) at the end of the address field, ------COUNTER: DEFINE CAMAC (C, n, a);

eg LOADX , PQR(1) ; The examples above carry out the same function. The quantities c, n and a are integers giving the simple expressions of the form crate, station and module sub-address respect­ ively. Symbolic name ± integer Direct CAMAC addresses can be modified by placing (1) after the CAMAC address. Here modi­ are also permitted. fication is performed on the N address alone and To enable the user to reference any word is taken modulo 32. within the computer store by its absolute address To permit CAMAC addresses to be defined at the virtual CAMAC processor provides for run time it is also possibll;l to specify that a indirect addressing through the data segment. CAMAC address may be found within the data Indirect addressing is declared by enclosing the segment. Here, the CAMAC address field will symbolic address of the data segment location contain either a symbolic reference to the data which contains the absolute address in parenthes­ segment location holding the CAMAC address or es, an indirect reference to some other location in the core store in which the CAMAC address can be found. The symbolic representation of direct eg STOREX , (RST) and indirect data segment addressing is the same for both CAMAC and store address fields. In the above example if RST contained 350 then the contents of the CAMAC processor X-register would be deposited in absolute store location 350. Indirect addresses can be modified either 2.5 The location field before indirection (pre-indexing) or after indirection (post-indexing). Pre-indexing is The location field fulfils three functions. First, defined symbolically by a store address field of it permits symbolic names or labels to be the form: assigned to locations within the 1/0 segment. Secondly, it is used with pseudo-operations to define data segment and CAMAC addresses (SYMBOL(1)) symbolically and, thirdly, it is used to define the In the above example, if the X-register contained name of the 1/0 segment. 5 and SYMBOL was location 20 in the data segment then the processor would access location 25 of the data segment for the indirect address. Post-indexing is defined by a store address 2. 6 Pseudo-operations field of the form: In addition to the executable instructions listed in (1) Tables 1 and 2 the assembly language also (SYMBOL) includes a number of pseudo-operations. These In this instance the contents of the X-register are used to permit the programmer to assign would be added to the contents of location SYMBOL symbolic names to data and program locations to give the indirect address. and to control the program assembler. The full Only one level of indirect addressing is allowed range of pseudo-operations is listed in Table 3. and in the present implemenhtion address modifi­ Reference 2 describes their detailed format and cation before and after indirection is illegal. use.

102 TABLE 3 CAMAC assembler pseudo-operations (Ref.l) 3. A typical 1 /0 program INE operations A typical program, written in CAMAC assembly DEF _ language, 1s shown in Fig.1. lt is taken from tuncname DE FINE FUNCTION, ( f1, f2) ; reference 2. The I/0 segment PROGOl is entered CAMAC name DEFINE CAMAC (C, N, A) ; on CAMAC interrupt from one of the two units FLAGl, which controls inputs and FLAG2 whi�h da a name DEFINE DATA < n1, n2> ; t controls outputs to an X-Y platter. These data name DEFINE DOUBLE ; modules are tested for L signals and on finding 1 it eral name DEFINE LITERAL ' L ; the unit generating the interrupt a jump is made to the appropriate section of code. On input, data Assembly Controlling operations from five consecutive modules is read into succes­ sive store locations. On output, a control word I/0 segment name BEGIN CAMAC and data word are written to sub-addresses 1 and END ; 0 of the platter control module. The example

PROG01 BEGIN CAMAC ; TESTLAM, FLAG 1, DUMMY, SEE IF FLAG 1 IS INTERRUPTING QSET, INPUT, JUMP TO INPUT IF YES ; TESTLAM, FLAG 2, DUMMY, SEE IF FLAG 2 IS INTERRUPTING ; QSET, OUTPUT, JUMP TO OUTPUT IF YES ; HALT, STOP NEITHER IS INTERRUPTING ;

INPUT: LOADX, = 0, CLEAR THE INDEX REGISTER ; READCL, EVENT (1), BUFFER (1) READ DATA AND CLEAR EVENT REGISTER ; INCRX, = 5, TALLY X AND CHECK WHETHER 5 EVENT READ ; JUMP, INPUT, MORE TO READ IN ; CLEARLAM, FLAG 1, REMOVE Q FROM FLAG 1; HALT, STOP AFTER INPUT PROGRAM

NOW START OUTPUT PROGRAM;

OUTPUT: WRITE, PLOTTER 1, CONTROL, SEND CONTROL WORD TO PLOTTER ; WRITE, PLOTTER, MOVEMENT, SEND DATA TO MOVE PLOTTER ; CLEARLAM, FLAG 2, REMOVE Q FROM FLAG 2; HALT, STOP AFTER OUTPUT PROGRAM ;

DATA AREA AND CAMAC MODULES DEFINED ;

BUFFER: DEFINEDATA, (0, 5)' RESERVE FIRST 5 WORDS OF DATA SEGMENT ; CONTROL: DEFINEDATA, (5, 1) ' PLOTTER CONTROL WORD ; MOVEMENT: DEFINEDATA, (6, 1)' PLOTTER DATA WORD ; EVENT: DEFINE CAMAC, (3' 10, 0) ' EVENT MODULES 10 TO 14 INCLUSIVE; PLOTTER: DEFINE CAMAC, (3' 1' 0)' MODULE 1 SUB-ADDRESS 0; PLOTTER1: DEFINE CAMAC, (3' 1' 1)' SUB-ADDRESS 1 FOR CONTROL OF PLOTTER ; FLAG 1: DEFINE CAMAC, (3' 8, 0)' INPUT CONTROL UNIT; FLAG 2: DEFINE CAMAC, (3' 9, 0)' OUTPUT CONTROL UNIT ; END, END OF I/0 SEGMENT ;

Fig. 1 A typical CAMAC assembly language program

103 shows one technique of searching for an interrupt the pseudo-operations. The format of the instruc­ and a technique for loop control using the X-regi­ tions can likewise be very readily modified provi­ ster of the virtual CAMAC processor. ding a very powerful tool for investigating differ­ ent implementations of the virtual processor. The assembler will be made available for a 4. The program assembler PDP-11 installation.

The program assem bler for the virtual CAMAC processor is implemented in PL/1 for use on the 1. LANGSFORD, A., 'An implementation of a virtual IBM 370/165 computer at Harwell. lt will CAMAC processor and its assembly language', AERE assemble programs coded in the assembly R. 6914. language described above and produces a block of 2. LANGSFORD, A., 'An implementation of a virtual CAMAC processor ', presented at the II European Real­ virtual object code which can be transformed by a time Seminar. 'plug-in' module to a form suitable for loading into the store of the computer used by the virtual processor. At present the 'plug-in' module is configured for a Honeywell DDP-516 and will pro­ Discussion duce an output tape which is compatible with the standard linking loaders of that machine. Q. How are the links established between the However, by replacing this module with another user's program and the virtual processor? of similar function, the CAMAC object code could be readily loaded into any other machine. A. Simply by the subroutine call: Programs for assembly are punched on cards in what is essentially free format. Individual CALL CAMAC (DATAS , PROGO1) language statements are delimited by semi-colons where DATAS is the data segment and PROGOl is and statements may extend over many cards. the I/O segment, declared: Symbols can be any number of alphameric charac­ ters in lengtli with the proviso that only the first· DIMENSION DATAS (256) twelve are significant, one of which must be a EXTERNAL PROGO1 letter. There is one exception to this rule. To Q. lt looks difficult: the user must combine ensure compatibility with FORTRAN the first everything in CAMAC by himself. Wouldn't it be character of the I/O segment name must be better to extend the language? alphabetic and only the first 6 characters are con­ sidered significant. All spaces within the source A. lt is not really very difficult. The user can text are ignored. assign symbolic names to the modules. Perhaps The assembly is carried out in two passes. In there will be extensions, b.lt you have to imple­ pass 1 a symbol table is built up and the various ment it starting with the facilities of FORTRAN, pseudo-operations are processed. Pass 2 per­ e.g. common data areas. forms the instruction assembly. Output from the assembler consists of a Usting of the source text Q. How do you get the CAMAC addresses into as it was read from cards and an edited Usting FORTRAN? showing the text as it was interpreted by the assembler. Errors detected within an individual A. Here is an example to demonstrate how you statement are listed immediately below the state­ use it. In the CAMAC part we would have ment in question and the assembler lists the symbols defined in the program in a series of SYMBOL : DEFINE DATA (6, 1); maps at the end of the program text. and in the FORTRAN part In designing the virtual CAMAC processor it was realised that there were alternative approach­ DIMENSION DATAS (256) es to the problem and that the present implementa­ EXTERNAL PROG tion would inevitably be modified or augmented in EQUIVALENCE (SY , DATAS (7)) the light of experience gained with its use. In CALL CAMAC (DATAS, PROG) particular, it was reasonable to suppose that the so the SY in the FORTRAN part is the same as instruction set would be extended and that the pro­ SYMBOL in the CAMAC part. (DAT AS in the cessor might be implemented on another computer FORTRAN part is enumerated starting from 1; or with a different instruction format on the the data segment in the CAMAC part is enumera­ DDP-516. The program assembler was structured ted starting from 0.) with these possibilities in mind. lt is table-driven and additional instructions and pseudo-operations C. This is a common problem - it arises when­ can be readily introduced simply by extending the ever an assembly language program uses variables table of instructions stored within the assembler in the same address space as a compiler language and by adding appropriate procedures to process program.

104 Q. How does this fit with the work of the ESONE C. In CERN we have a different approach to the software group? problem, and generate code in-line. This elimi­ nates the need for the user to remember all the A. lt is near but not coincident with that. CALLs, etc.

Q. Can you say something about the external pro­ Q. How do you debug this? cessor and virtual object code for the PDP-11 ? A. By trial and error. We do not have any A. Not at this time. We are still working on it. special debugging tools, and recognize the deficiency.

105 System software real-time testing aids

W.E. QUILLIN Plessey Radar, The Plessey Co, England

1. General methods of software system build-up INPUT INPUT DATA 1.1 Design - HANDLING f---+- BASE DATA PROGRAM UPDATE Before the use of testing aids can be considered it is helpful to consider the way a system is built. The system design is a top- down process, which SYSTEM takes the system from an overall specification to DATA the design of individual program_ modules, which BASE will be coded, tested and integrated to build the complete system. The design process also leads - to the choice of suitable hardware. OUTPl!J OUTPUT DATA BASE HANDLING t-+- EXTRACTION 1--+- DATA PROGRAM PROGRAM 1.2 Off-line testing

System Implementation is a bottom-up process, TEST 1 INPUT HANDLING PROGRAM TEST 2 OUTPUT HANDLING PROGRAM starting with the testing and integration of the TEST 3 INPUT HANDLING PLUS DATA BASE UPDATE lowest levels of the modules. Initial testing will TEST 4 OUTPUT HANDLING PLUS DATA BASE EXTRACT be in an off-line environment, in either a free­ TEST 5 COMPLETE SYSTEM standing computer of the type for which the object Fig. 1 code is intended, or in a computer of a different type, generally larger, which has a suitable emulator program. lt is important that this off­ further off-line tests, or to do so would involve line testing stage should be -as thorough as pos­ the production of an unacceptable amount of test sible, and remove all the coding hlgs and design program or test data. At this point on-line testing errors it can possible catch. A single free­ is started, and it is at this time that system standing computer is usually much easier to testing aids are required. Like the off-line tests, obtain and control for testing purposes than a the on-line testing starts with as simple a system complete on-line system. Some routines can be as possible. The code is tested in its final object very extensively tested in this manner, others computer, but not all the other system computers are much more difficult to off-line test, especially and the full input-output facilities will be provided if they control complex interface equipment with initially, see Fig. 1. Part of the job of the on-line real-time constraints. Not only single modules, test aids is to cover up the lack of these facilities hlt suitable collections of related modules, will and make it appear to the code under test that it be tested off-line. Input and output modules of is in its full system environment. The testing these collections will be replaced by dummies, aids are primarily intended to help test the soft­ and assistance in the testing is provided by a set ware, and leave it to a pre-test checkout or hard­ of off- line testing aids. The majority of faults ware detection routines included in the package which escape detection at this off-line testing under test to find any system hardware failures. stage will be interface errors and errors due to The problem with a real-time system is that it is the constraints of real-time working. not designed to be capable of stopping and then being restarted. Hence the use of freeze-points in the code to trap errors is generally inappro­ 1.3 On-line testing priate. The testing must take place with the system in operation and it is highly desirable that For each package of modules there comes a time minor changes can be made, whilst the system when either it is not possible to carry out any continues to run.

106 2: Requirements for system testing aids found easier in a slow running system - the ulti­ mate in slow running a system is to be able to Testing aids are required to fulfil the following 'One- Shot' it, and the system testing aids should functions in a software system under development. mak.e this possible, in conjunction with the on-line operating system. Other system faults may 1. To inject data into the system under test. require the system to run faster than real-time, The simplest form of data injection required is this being especially true of faults which require the addition of items to stacks, queues and lists assistance of engineers using instruments, e.g. in the system, to check that the processing of this oscilloscopes. Testing, both hardware andsoft­ data is initiated and performed correctly. Such ware, is designed to ensure that such faults are requirements generally arise because the system rare, but they cannot be completely eliminated. under test is incomplete. The need also arises A facility should also be provided to enable part sometimes during testing as it becomes necessary of the program under test to be continuously to exercise a suspect program on a more rapid repeated, as an aid to finding intermittent and basis than would be the case in normal use. other seldom occurring faults. Another type of data injection is the on-line amendment of contents of common core store and 4. The system testing forms part of the total computer core store. This gives test personnel documentation. This is required to give a record a method of controlling the running system, of the testing methods used and to assist in the temporarily masking faults to enable other faults tracing of faults which occur during use and to be found, and, if they are not careful, comple­ during subsequent software or hardware modifica­ teley wrecking the software under test. lt is a tions. The system testing software can assist facility which must be used with caution, particu­ this documentation task by giving a print-out in a larly when changing computer core store contents suitable form for incorporation in the documenta­ if the computers have a relocatable loader. The tion. system testing software should enable tasks of the system on-line operating system to be initiated 5. Frequently during testing the designed or suspended during the test by suitable data method of system start-up and shut- down is injection. inappropriate due to the need to run with parts of the system incomplete and the desire to reduce 2. To extract data from the system for sub­ testing time when possible. The system test soft­ sequent analysis. Once again the simplest case ware should enable various start- up and shut-down is extracting data from a stack, queue or list. procedures to be followed as appropriate to the There are two cases here, one where the queue test being conducted. or list forms the end of the process under test, i.e. the program which would usually empty it is not yet included. In this case the testing aid must 3. Examples of testing software successfully used on remove entries at a suitable rate to prevent on-line systems unwanted list or queue full indications. The second case is more complicated, where the list The following examples consider two on- line test or queue is an intermediate point in the software programs written and used by the Plessey Co. for under test. In this case the test program must testing on-line software. They are currently look at and record entries but not remove them. being modified �.

107 arranged that inputs can be accepted from paper 3. 5 There are also four clear and erase tape and the computer control console as the messages: positions' keyboards. In practice these first two i Clear a whole display. options have rarely been used. ii Clear right side of display. iii Clear left side of display. iv Erase last character injected.

1 2 LEFT SIDE RIGHT SIDE 3.6 There are comment messages which are 3 DISPLAY DISPLAY given to the operator upon a fault condition. 4 AREA AREA s ( LHS) (RHS) i Wrong Key - Try Again. 6 7 LHS COMMENT LINE RHS COMMENT LINE This is displayed upon operation of an illegal 8 LHS MESSAGE LINE RHS MESSAGE LINE alpha-numeric key. lt is cleared on a valid 9 injection . 10 DATE MONITOR POSITION TIME ii No Data message displayed. This is displayed if an operator attempts an Auxiliary Data message when no Data message Fig. 2 Basic display for EDD monitor has been injected. iii Common core address invalid. 3.2 The basic display is shown in Fig. 2. lt If the full address field is not used for common requires a position with at least a 10 line display core store addresses and an out of limit request facility. The program will operate if using a is made, this message will be displayed. position with only 8 lines (in one case some posi­ tions had only 8} but the Date, Monitor Position iv Faulty Transfer. and Time Displays are then not available. The After an inject to store message the program position in use is set up at the start of a trial and sends the data, then reads it back as a check. can be changed if required during the testing This message is displayed if the check fails. period. Each side of the display is treated inde­ pendently and on each side there can be displayed v lnject lnhlbited. up to six words of eight or twelve digits. Data is lt is sometimes necessary to inhibit the injection loaded into the display formats from the top and of data, for example during system trials. This if a smaller number of words than six is inhibit is controlled from a computer console key. required the lower data lines will remain blank. The above message is displayed if the operator tries to inject whilst this key is operated.

3.3 There are four types of data messages: vi Computer Not Available. i Display up to six words from a common Whilst transferring injections to or from another core store. computer the program expects a confirm reply. ii Display up to six words from a computer If this does not arrive in a predetermined time, store. the above message is displayed. iii Inject up to 6 words into a common core store. iv Inject up to 6 words into a computer store. Data is set up on the monitor in octal. In the case 1 5252 5252 5252 7654 3210 2 7777 7777 7777 0123 4567 of injections to core store, the operator must 3 6666 6666 6666 1212 1212 confirm the data and then inject, giving ample 4 5555 5555 4444 5151 5151 chance to remove an error. Repeated injections s 7777 7777 of the data set up are possible. 6 0000 0000 7 WRONG KEY - TRY AGAIN 8 OS --5 004A1000Q41 --C002A 122222*RY* 9 3.4 There are also four possible auxiliary mes­ 10 28 FEB 71 14 11 15 10 7 sages: i Add 'nn ' to a given address (nn is a two­ digit octal number) . Fig. 3 Sample format of EDD monitor ii Subtract 'nn' from a given address. iii Continually update displayed data . iv Freeze display. 3. 7 Figure 3 shows a sample format. The left The first two apply to any of the Data messages, side display "--S 004 A 1000 Q4 I" means inject the second two only to Display Data messages. the four words of data into store 004, starting at

108 address 1000. The 05 is the number of times this There are a number of program usable control data has been injected. The operator has operated keys on the computer consoles. Keys one to twenty an invalid key. The date is 28th February, 1971. can be used to switch individual directives on or The right side display message "--C 002 A off if they specify the key number. 122222*" means display 6 words of data from As well as pre-loading the common core stores computer 002 starting at address 122222. The the program can be used to start system compu­ Auxiliary Data Message RY* means continually ters in any order by sending specially coded mes­ update the display. The time is shown as sages to them, whilst they are in a start-up state. 11.15 10.7, i.e. 10.7 secs after quarter past Queues, Lists and Data areas can be referenced eleven. by a CORAL name instead of the store number and address. This is arranged by a declaration of the form 3.8 Experience with this program has shown that it makes it possible for an experienced system * store number store address test team to locate errors by working in an inter­ active fashion with the running system. The use where * is either Q, L or D for queue, list or data of a display enables many data items in computers area. and common core stores to be scanned rapidly, to find for example where a chain of events breaks. S 2, 3, 15 Data changes of ¼ sec can be detected on the dis­ play enabling entries in queues and lists to be K1 T 1 47 .5 seen between addition and removal. WDS 3 A 1250 C 1234 5670 1234 C 5252 5252 5252 4. SCOT program T3 30.0 The second system test aid program to be EQS 4 A 1000 described is called SCOT (System Computer On­ line Test) and covers testing functions described in paragraph 2 which are not covered by the EDD Fig. 4 SCOT input message example Monitor program, such as adding data to queues, giving output suitable for documentation and system start-up. Whereas the EDD monitor pro­ 4.2 Figure 4 shows an example of a SCOT input gram is designed for searching for faults and message. First the stores in use for the test are obtaining small amounts of data (by writing down declared, in this case 2, 3, and 15. display contents or photography) the SCOT pro­ The next message is to write to store 3, gram is used to obtain large volume outputs. address 1250 the two words given in octal. This is after 1 min 47.5 secs, and as KI is specified it 4.1 The following description of input messages will only be obeyed if computer console key 1 is shows the program 's capabilities. operated. i Specify common stores in use for the test. The next message, which is independent of the The address numbers of the stores to be console keys as none is specified, should be used are input. actioned at 3½ min after the program starts. lt is ii Place data in common stores. From one to extract data from a queue in store 4, address word up to a complete store may be set up. 1000. In fact, it will result in an error when it is iii Extract all entries from a queue and reset read into the computer, as only stores 2, 3 and control word. The entries extracted are 15 have been declared for the test. printed out. iv As above, for a list. v Compare Data in a specified area of a com­ 4.3 Figure 5 shows the form of a SCOT output. mon store with its previous contents. Any First the start time is output if the program has differences are printed out. access to the system clock. Then the system vi Add an entry to a queue. stores in use are shown, not exactly as depicted vii Add an entry to a list. here as the present version outputs the store Write directives (ii), (vi) and (vii) must be pre­ availability table built up as a result of the store ceded by a time-tag which can range from ¼ sec declaration input. However, this example has upwards in steps of ¼ sec. Extract directives been simplified to make it more clear, and avoid may be time-tagged. If they are not, they will be a need for system table layout knowledge. executed every ¼ sec. A choice of time sources is The next output message echoes the input which provided - the program will use a system clock if was to write to store 3, address 1250 the two available, if not a programmed timer can be used octal constants shown, as a check that this action - which is less accurate. was completed.

109 START TIME 12 45 52 25 (c) Access faults. SAL 02 i QÜeue full. ii List full. SAL 03 iii Queue locked out too long. SAL 15 iv List locked out too long. Str 3 Adr 1250 v Computer failed to start. The time is given along with the above five fault C 1234 5670 1234 reports. C 5252 5252 5252 Emin 3 sec 30.0 Str 3 Adr 1000 4.5 Experience has shown SCOT to be a valuable C 0003 0003 0401 cnt 3 tai 1 hed 3 syste-m testing aid. It is particularly good at C 0357 4732 0101 eliminating interface errors before system inte­ C 0 gration tests. To achieve this, the programmer who is writing say a program to extract data out C 3716 5125 3076 of a queue and process it will get a programmer C 1327 0312 7766 whose code would normally help fill the queue to -- provide a test tape, thus ensuring no misunder­ Fig. 5 SCOT output message example standing. The hardware tests of common core stores were included in SCOT as a 'long stop' to help show any faults which may arise during a test. The next output message is the result of read­ These checks have shown faults during test runs, ing a queue in store 3, address 1000. Note that but these have generally been due to manual equip­ it is a queue of five words (four plus a control ment allocation errors, not hardware, when a word} the maximum length being shown in the store has been out of system when required or control word. The control word also shows where removed in error during a test. A system is more the head is (word 3), the tail (word 1) and the prone to such errors during build-up time as the count of entries (3 in this case). These are output tests do not often require the total system and as decimal integers as shown. other activities are allowed to use the spare equip­ ment.

4.4 Error reports from SCOT fall into three classes. 5. Hardware assistance with system testing (a) Input faults. i Fault in common core store declaration or The constant problem during testing is one of data no stores declared. collection - finding out what state the system was ii Fault in octal constant. in just before it faulted. Up to now this assistance iii Fault in number given for common store, has usually been arranged by special software, out of range or not declared. and this paper has considered in detail two pro­ iv Address fault. grams which have been used to achieve this. It is v Fault in decimal number. also possible to arrange for the system hardware vi Fault in time given. to collect data to assist in on-line testing. This vii Fault in name declaration. can be by hardware built-in to the the system or viii Name not declared. special-purpose test equipment which can be attached. These alternatives are now considered. (b} Store faults. i Initial check unsuccessful. The stores declared are checked at the start of the 5. 1 Faci/ities bui/t-in to the computer hardware test, and should this check fail this mes­ sage is output, along with the data sent, In the case of real-time computer systems there data received and the store number and are a number of ways the hardware design can address. help the system testers. Historical registers and ii Transfer of data unsuccessful. Data written test driver facilities are examples of these. to a store is read back and checked. If the i Historical registers. check fails, this message is output along The computer contains a group of, say, with the four items as in (i). sixteen registers addressed sequentially so iii Routining fault. Every ¼ sec a routining they form a circular queue. When an pattern in a reserved word in every store instruction involving a single store operand is checked. A fault causes this output is obeyed, three values are placed in these along with store number and data returned. historical registers: 110 Instruction Address Register, Absolute necks. Some are equipped with an address com­ Value. parator which can be used to show, for example, Instruction. the amount of time spent in the operating system Store Operand Address. routines. Once experience is gained patching such The third item is omitted if the instruction monitors into a system they can quickly provide does not involve an operand address. Hence detailed information on suspected fault areas the last six or seven machine instructions without requiring special on-line software. obeyed can always be found in the historical registers. Their contents can be frozen by either a fault interrupt or by program con­ 6. Conclusion trol, and their contents then extracted. ii Test driver facilities. Experience has shown that time and money spent Special interface facilities can be provided on providing system testing aids has been essential so that the computer may be test-driven by to the testing of on-line system software, from the another computer (of the same or a different start of first on-line tests up to final system type) which can access its registers and core trials. Even after a system becomes operational store. This enables a trace of the compu­ some faults will continue to occur and the test ter's activities to be obtained du.ring real­ aids have a continued value. time working, when a software trace facility As the cost of hardware decreases and computer is inappropriate due to the slowing down of designers pay more attention to software needs, run time (typically by a factor of 80). more assistance is likely to be given by special circuitry to the on-line testing of computer sys­ tems. 5.2 System attachments

System attachments can be obtained for data Discussion recording. These are generally similar to the historical registers described above, wt they are Q. Do your debugging aids run as part of the portable and will usually interface with any con­ user's program in real time? venient points of the system, e.g. store data lines, store address lines, interconnection buses, peri­ A. Yes. lt depends on having enough capacity in pheral devices. Data is recorded in special regi­ the computer, which we have. sters or on magnetic tape for subsequent analysis off-line. They are particularly useful towards the Q. Is it possible to make the program run more end of system testing to measure use factors of slow ly than normal? connection channels and look for system bottle- A. Yes, the rate can be controlled.

111 Testing and diagnostic aids for real-time programming

E.C. SEDMAN Computer Analystsand Programmers Ltd, Reading, England

1. lntroduction

Most papers on computing topics tend to be con­ "t:lr QJ cerned with the design of programs or systems, "'Ol Ol but experience indicates that this is only a small C: \ QJ lntegrate & System Test part of the total effort involved. Aron Il] states QJ. "' \ Q) C. 40% that 30% of the elapsed time of a large project is 0 QJ spent on design, with 40% on implementation and C. \ Q) 30% on testing. Figure 1 is a simplified form of ....0 Code & c:: Unit Test \ Aron's diagram, which shows how the number of 0 z: 40% people engaged in a project changes during the life 20% ' ' \ of the project. In terms of resources, the ratios Design ' are probably more like 20%, 40% and 40%, so it is worthwhile to consider the aids available to 30% 70% 100% improve performance in these latter stages. Elapsed time Real-time systems introduce a number of special problems, and this paper discusses them Fig. 1 Time dependence of resource utilisation under two main headings. Section 2 deals with testing, i.e. getting rid of bugs before the system goes live. Section 3 deals with diagnostic aids, i.e. finding the bugs which were not got rid of essential however because of the large number of before the system went live. interactions that can take place.

2.1 Test environments 2.2 Special hardware

lt is common practice to create a test system to In process control and similar applications, one facilitate the unit testing of individual components is frequently dependent on special hardware such and also the testing of functional packages. Such as analogue to digital converters, non-standard a tool has been described by McKenzie and Weston interfaces, etc. A good general rule is not to [ 2]. While not peculiar to real-time programming, trust it - the combination of untried software and it is particularly valuable for this because bugs untried hardware can be a nightmare. which are not found at the unlt testing stage can be When starting system testing under such cir­ very difficult to find at a later stage. cumstances it is often useful to drive the pro­ A particular point is that the test system should grams using simulated inputs. The routine which not zero out blocks of core before they are given services the special device is replaced by a to the program under test, if this will not happen dummy which supplies predetermined values. A in the live environment. lt is even better to over­ good example of this used the standard service write the block with some arbitrary pattern when routine to issue a 'read' and service the interrupt, it is returned to the system. This will help to but it then ignored the data so obtained and took detect errors resulting from references to data values read in from the disk. In this way valid that is no longer a vailable. One should generally timings were obtained, but one could also repro­ try to prevent future trouble that could arise from duce a test run without having to worry about implicit assumptions about control program inter­ whether the hardware was behaving consistently. faces. Of particular value \Yas the ability to introduce The use of programming standards and conven­ incorrect values in a controlled way, in order to tions, for example in the use of registers, is check that the programs behaved correctly in similarly not special to real-time. Their use is error situations.

112 ------

On the output side the same thing applies: the The problems of providing a 'warm restart' can fact that equipment is not behaving in the way that easily be underestimated, and an error arising it should, does not necessarily mean that the during this procedure can be a major difficulty. wrang values are being output by the program. It Reconfiguration after an error must be checked is therefore worthwhile to have a means of record­ out, and a requirement to run in degraded mode ing the values being output to a device. implies that such running must be tested. One of the most sophisticated simulations of It is often necessary to provide a file recovery this type has been used in the Concorde fatigue program. This enables records that have been test, where independent computers are used for lost or corrupted to be repaired. When such a control and monitoring. To test the system out, program operates on records that are chained the computers were run 'back-to-back ', with the together, it is particularly important to test that output from the control computer fed directly to no harm comes from an attempt by another pro­ the monitoring computer. gram to access a record which is currently under­ As well as providing simulators to drive the going repair. software, it is also useful to have simulators to Finally, it is necessary to test the recovery drive the hardware. This mean essentially simple from hardware errors as well as software errors. programs to exercise the hardware and record For example, the action tak.en in the event of a the results. Such programs often have an extended disk read failure is often not tested until such a lüe for diagnostic purposes long after the initial failure occurs. To produce a reliable system, it testing stage, but they are often best devised by a is necessary to check out all such actions hardware expert who understands the way the hard­ (perhaps by simulation) before the error arises ware works. A further point to be borne in mind in practice. is that the diagnostic programs should be able to be time-shared with other work, or one can find that the whole computer is being used to check out 3.1 Tracing one minor device. One of the simplest, but often the most useful debugging aid is a list in order of, say, the last 2.3 Terminal driven systems 20 routines called before the crash. If one has a standard method of entering routines, there is In the case of systems with a large number of on­ very little overhead involved in storing in a circu­ line terminals, one has a different hardware lar buffer a code number for each routine as it is problem. Either the hardware is not available entered. It is usually worthwhile to keep such a when the system is being developed, or, if it is, list for each task. one does not have the staff to drive all the termi­ A more elaborate facility is a dynamic trace nals at once. Even if one had, there would again that can be activated or deactivated selectively be the problem of lack of reproducibility, so again from a terminal. Its output can be written to one has to provide a means of simulating inputs. magnetic tape for subsequent off-line analysis. On one such system, it is possible to run card Again the facility has to be bunt into standard based tests of the version under development, entry and exit procedures. It involves some over­ concurrently with terminal usage of the live sys­ head, but its great advantage arises if it can be tem. For this particular case, only single-thread initiated selectively when there is trouble, without testing is currently available, but multi-thread the need for any recompilation. testing is desirable. The problem here is that Sometimes the only way to find a bug is to concurrent tasks will not always terminate in the introduce snapshots in the routine where the same order on successive runs, due, for example, trouble is thought to be. This involves recompila­ to differences in disk arm movement. It is tion of course, but can be made easier if a stand­ especially important to check that the correct ard routine exists which can be simply called. action is tak.en when a task fails to obtain a resource. This is a special case of the general testing of limit conditions and should include look­ 3.2 Consistency checks ing for 'deadly embrace' situations. Volume test­ ing of any exclusive read facility is desirable, With a multi terminal system, one can differentiate while dealing with the maximum number of siJ:p.ul­ sharply between errors which affect one user, and taneous transactions will help to show up any non­ errors which affect the whole system. For errors reentrant coding. in the first category it is usually possible to 'kill' the user concerned, but to keep the rest of the system working. Errors in the second category 2.4 Error recovery usually bring the whole system down. lt is there­ fore good practice to carry out consistency checks An important area that is often insufficiently on all data handed to the control programs, and if tested is that of error recovery and restarting. possible to carry out the checks at as early a

113 stage as possible in the application programs. had been suspected but not identified for an even Failure of such a check results in a selective dump longer period. of information about the particular user and the termination of his task. A typical check can make use of a record 3.4 Footprints identifier. When reading in a record from disk an identifying character is checked to ensure that the When a common data base can be updated by many record has not been corrupted. Equally, before different application programs there are always writing out a record, the character is checked as garbage disposal problems, but more serious are a protection against the record having been over­ the problems of records which have been disposed written in core. Similarly, it is possible to have of when they are still required. To check on this a block identifier. When a program is given a it is possible, each time a record is released, to core block by the control program, it can check log information about the program doing the that its address is in an acceptable range, and releasing. In this way one can obtain evidence also check a character in the block which indicates about programs which release records that are its size. In this way one can avoid problems still required. arising from blocks being put onto the wrong lists when they are released. Again, when updating a record the program 4 Conclusion doing so must have exclusive access to the record, i.e. it must 'hold' the record. lt is possible to The above has been in the nature of a review of keep a check on exclusive reads, and· ensure that testing and diagnostic aids. lt is hoped that it will this is the case before updating. be of some use as a check list, and also perhaps In designing a real-time system, redundant encourage the dissemination of other ideas that information of this type should be inserted could be generally used. deliberately to provide additional checking.

1. ARON, J.D., 'Estimating resources for large program­ 3.3 Monitoring ming systems', NATO Science Committee, Software Engineering Techniques - report on Conference, Rome One of the problems with the consistency checks (October 1969). mentioned in the previous section is that the 2. McKENZIE, K.1., and WESTON, P.J., 'An extended toolkit for PDP-10', DECUS Europe 6th Seminar, damage may have been done some considerable Munich (September 1970). time before it was detected, with the result that it may be very difficult to find the cause of the trouble. To overcome this, a monitor can be Discussion introduced, which carries out checks at regular intervals, to try to detect corruption as soon as it Q. Which computers did you use for the Concorde occurs. The best chance of pinpointing the fault fatigue test, and which languages did you use to will be if the check is carried out on every sub­ program them? routine entry, but it is adequate to check each time a task is scheduled because another has A. There are three computers. Control of the terminated or gone into a wait. Under these cir­ loads is by a PDP-8. Control of pressures, cumstances the task causing the trouble can be temperatures, etc. is by another PDP-8 with determined uniquely, and hence from the trace special hardware and software supplied by Kent one can obtain the sequence of routine calls Instruments. The monitoring computer is a 48K responsible. word DEC system 10 (PDP-10). The information to be checked can be anything The most difficult programming is on the moni­ which is known to become corrupted. Typically toring computer. We did detailed design of the this might be a chain of core blocks each of which programs in PL/1, and they were translated by contains pointers to the next one and the last one. hand to Macro-10 by a more junior programmer, lt is possible to chase down such chains, carrying who also tested them. This worked fairly well out a consistency check, and when an address is because two people worked on every program, and incorrect it is known that overwriting has occurred. there was some element of competition because This is another example where use is made of the junior tried hard to find logical errors in the redundant information designed into a system. In design given to him. lt was not completely succes­ one case, the use of this technique rapidly identi­ sful because corrections tended to be made to the fied a major bug which had been causing trouble Macro-10, without the PL/1 being updated. but had remained unsolved for several months. lt also detected four other bugs whose presence

114 Real-time programming using a real-time language of intermediate level

B. EICHENAUER Elektronik System GmbH, München, W. Germany

1. lntroduction involves the development of intermediate-level The higher programming languages such as languages like CORAL66 [ 8] , allowing only for the ALGOL 60, FORTRAN and PL/1 for digital com­ algorithmic program parts which can be translated puter systems used in business, technology and in efficient code. In these languages most of the science have enabled users with little knowledge features relevant to real-time programming, i.e. of the systems themselves to use them cost­ tasking, timing and process-I/O, are left quite effecti vely in practice. On the other hand, users open. Real-time programming is carried out by who wish to solve real-time problems by digital calling the functions of the target-computer computers must have comprehensive experience Operating system. in handling their particular types of machines, This means of simplifying the problem may and have to spend much time in formulation and allow faster formulation of programs, as com­ debugging of programs. pared with assembler programming, but the main The last few years have seen several attempts disadvantages of current methods are still present. to simplify the use of digital computers in the For instance, every user must know the actual field of real-time applications. Today, there are surrounding manufacturer software nearly as weil -essentially three views on how the difficulties can as when using assembler languages. The docu­ be overcome. mentation and the portability of programs is The first way, pursued since the beginning of restricted by the dependence of the target compu­ the sixties, involves the development of special­ ter. purpose packages [1, 2, 3] and problem-oriented The third method, used, for example, in languages [ 4, 5, 6, 7] for special fields in real­ 1NDAC8 [9], PASl [10] and PEARL [11], consists time applications. in adding to algorithmic language features of Experience in the use of special-purpose intermediate level a sufficient set of basic real­ packages and of problem-oriented languages time and I/O features of comparable language shows that differences between problems in one level. As the algorithmic features of intermediate­ application field are usually so substantial that level languages such as ALGOL or FORTRAN can only a small part of the field for which a package be used to formulate any numerical algorithms, or a language was made can be covered. With the the basic real-time features should allow separa­ development of technology, packages and problem­ tion of application problems in loosely connected oriented languages have to be modified, resulting processes [12], and formulation of any corres­ in a great number of packages, problem-oriented pondence of a process with the surrounding world. languages and dialects of these languages. In the A detailed explanation of the above set of field of automatic check-out, for instance, there language elements cannot be given here. Instead, are at least 30 languages and dialects, but to my we describe the solution of a simplified automation knowledge not one of these languages can com­ problem in the E_rocess and �xperiment �utomation pletely formulate the simple function test problem real-time language PEARL, which we believe to treated below on language level. be the most advanced language for real-time The second way to overcome the difficulties programming at present.

115 T EST STATION 1 ----=------=i=------�� GREEN1 RED1 "'-::: ------:'II------

T E ST STATION 2 - "<:::T-T- - =-=---=-� GREEN2 ---=_ - ----___�.....,..R E D2 "'=T- l'=- =� ==-= =:CO NCT2 1-t-----+---t------cu RR2

-----+---'------+--+------START2

POW E R SUPPLY

1------1VOLTA GESELE CTOR ------...i E __-______.....,.. P OW RSUPPLY 1

Fig. 1 Test installation

2. Programming example the diode to one of the test stations. Then the start button of the chosen test station is pressed The example is takenfrom the PEARL report to start the test program of the station (input from [ 111 . STARTl resp . START2). The test program applies the reverse voltage 2.1 Problem to the diode (output to CONCTl resp . CONCT2), measures the reverse current (input from CURRl Figure 1 shows a test installation consisting of resp. CURR2) and removes the reverse voltage two identical test stations and of a programmable (output to CONCTl resp. CONCT2). power supply. The function test for four different If the measured reverse current exceeds a types of diode has to be carried out at the test type-dependent maximum, a red lamp on the stations. instrument panel has to be switched on for 2 sec After the start of the automation program by (output to REDl resp . RED2). Otherwise a green the operator the computer switches on the power lamp is switched on (output to GREENl resp. supplies of the two test stations (output to GREEN2). POWERSUPPLY) and adjusts the reverse voltage The number of diodes not ope·rating and the depending on the type of diode to be tested (output total number of diodes are counted for every test to VOLTAGESELECTOR) . station and must be recorded at the end of the The first step of the function test is to connect test period, or the type of diode must be changed.

116 Channel 1,Bit 1-6 . VOLTAGE ­ SELECTOR Channel 2, Bit 1-2 . POWER ­ SUPPLY Channel 2, Bit 3-4 RED1 D igital Channel 2,Bit 5-6 Output ..r GRE EN1 ,----, Device : Channel 3,Bit1-2 DIGOUT ..RED2 Channel 3,Bit 3-4 GREEN2 Channel 3,Bit 5-6 CONCT1

Channel 1 Channel 4,Bit 1-2 CONCT2 Computer: Channel: ...,Channel 2-3 ... .. COMP . CHAN :channel 4

...... "� � A/D Gon- Channel 1 �... CURR 1 verter: Interrupt line 3 ADCMUX R Channel 2 "'T ADCMUX CURR2 GON- SOLE„ 1/0 Device: lnterruot line 4 TTY READY TTY lnterruot line 12 START1

Interrupt line 13 START 2

Fig. 2 Configuration of process periphery

2. 2 Configura tion of the computing system have to be identified by names. The automation algorithm for the function test Figure 2 shows the configuration of a hypothetical problem has been divided into three parallel resp. computing system servicing the test installation. quasi-parallel executable program parts named TESTPROB, TEST1 and TEST2. The main-task TESTPROB is activated by the 2. 3 Automation program operator by input to the standard-I/O-device CONSOLE (e.g. with the control statement: The PEARL automation program consists of two ACTIVATE TESTPROB PRIO 3). program sections - the so-called SYSTEM-section To allow for parallel working of the test and the PROBLEM-section. fu the system section stations the service programs for the stations are the configuration of the computing system shown isolated by introducing the tasks TEST1 and TEST2. in Fig. 2 is described. To allow for configuration­ TEST1 resp. TEST2 will be activated after inter­ independent programming of automation algorithms rupt START1 resp. START2 has occurred. in the problem division, all process end-points

MODULE LIBRARY DIODETEST; /* PEARL EXAMPLE PROGRAM : FUNCTION TEST PROBLEM *f SYSTEM; I* CONNECTION OF STANDARD DEVICES: *I COMP <-> CHAN; CHAN * 1 -> DIGOUT; * 2 * 1,12 <- ADCMUX; * 4 <-> CONSOLE: TTY; 117 I* PROCESS END POINTS: *f VOLTAGESEtECTOR: <- ÖIGOUT * 1 * 1,6; POWERSUPPLY: <- *2*1,2; RED1 : <- * 2 * 3 , 2; GREEN1 : <- * 2 * 5,2; RED2: <- * 3 * 1,2; GREEN2: <- *3* 3,2; CONCT1 : <- * 3 * 5,2; CONCT2: <- * 4 * 1,2; CURR1 : -> ADCMUX * 1; CURR2: -> * 2; f* CONNECTIONS OF INTERRUPTS : *I CONTACT(3) <- ADCMUX * R ; CONTACT(4) <- TTY * READY; START1 : CONTACTC12) <- START2: CONTACT(13) <- I* END OF SYSTEM DIVISION *I PROBLEM; DCL (START1 , START2) VAL INTERRUPT; TASK TESTPROB GLOBAL HANDLE: BEGIN DCL f* STANDARD OUTPUT DEVICE: */ STANDARDWRITE VAL DVC = CONSOLE, /* VARIABLES TO COUNT THE NUMBER OF TESTOBJECTS: *f (TOTAL1 ,TOTAL2, NOGO1 ,NOGO2) INT := 0, f* VARIABLE TO STORE THE UPPER LIMIT OF REVERSE CURRENT: *f TYPECURR INT, I* STRINGS TO ADJUST THE POWERSUPPLY TO REVERSE VOLTAGE: *f ADJUSTC1 :4) VAL BIN(6) = ('1000' B,'100'B,'10'B,'1 'B), /* UPPER LIMITS OF REVERSE CURRENT: */ MAXCURR(1 :4) VAL INT = (50,35,28,20) , I* COMMON CHARACTER STRINGS: *f TEXT1 VAL CHAR(13) = 'TEST STATION ', TEXT2 VAL CHAR(28) = ': NUMBER OF TESTED DIODES = ' , TEXT3 VAL CHAR(27) = 'NUMBER OF INFERIOR GOODS = I* COMMON FORMATS: *f COM1 VAL FORMAT = F'S(13) ,S(1 ) ,S(28) ,,L ', COM2 VAL FORMAT = F'(16)C,S(27) '; - f* TEST PROCEDURE: * / DCL TEST PROC REENTRANT = ((UAMP,CONNECTOR ,REDLAMP ,GREENLAMP) VAL DVC, (TOTALNUMBER , NOGONUMBER) INT ) BEGIN DCL CURRENT INT; TOTALNUMBER := TOTALNUMBER + 1; /* MEASURE REVERSE CURRENT: *f MOVE '1 'B TO CONNECTOR; MOVE UAMP TO CURRENT; MOVE '10'B TO CONNECTOR; 118 f* CONTROL OF REVER SE CURRENT: */ IF CURRENT > TYPECURR OR CURRENT < 2 THEN I* NOGO 8RANCH: */ MOVE '1'8 TO RED LAMP; DELAY 2 SEC; MOVE '10'8 TO REDLAMP; NOGONUM8ER: = NOGONUM8ER + 1; ELSE I* GO 8RANCH: *f MOVE '1'8 TO GREENLAMP; DELAY 2 SEC; MOVE '10'8 TO GREENLAMP; FI; END /* OF TEST PROCEDURE */ f* DECLARAT ION OF TASKS TO CONTROL THE TEST STATIONS: *f TASK TEST1 : CALL TEST(CURR1 ,CONCT1 ,RED1 ,GREEN1 ,TOTAL1 ,NOG01); TASK TEST2: CALL TEST(CURR2, CONCT2 ,RED2, GREEN2,TOTAL2, NOG02) ; I* GET THE TYPENUM8ER OF DIODE UNDER TEST: *f TYPEDEF: WRITE (DATE,TIME,'TYPENUM8ER : = ') FORMAT( (2) (,(2) C) ,S(14)); READ TYPECURR FROM CONSOLE FORMAT(, (2)L) ; IF TYPECURR < 1 OR TYPECURR > 4 THEN WRITE 'INPUT ERROR: UNDEFINED TYPE' FORMAT( (10)C,S(34) ,(2) L) ; GOTO TYPEDEF; FI; f* SWITCH ON AND ADJUST POWERSUPPLY : */ MOVE '1'8 TO POWERSUPPLY; DELAY 2 MIN; MOVE ADJUST(TYPECURR) TO VOLTAGESELECTOR; /* STORE LIMIT OF REVERSE CURRENT AND INDICATE TEST 8EGIN: *f TYPECURR := MAXCURR(TYPECURR) ; WRITE (TIME, 'TEST 8EGIN') FORMAT (,S(10) ,(2) L) ; I* CONNECT START INTERRUPTS TO CONTROL TASKS: *f ON START1 ACTIVATE TEST1 ; ON START2 ACTIVATE TEST2; f* SUSPEND MAIN TASK TESTPROB UNTIL OPERATORS' COMMAND: CONTINUE TESTPR08; *f SUSPEND EXEPT TEST1 ,TEST2; f* RECORD OF TEST RESULTS : */ WRITE (TIME,' TEST RESULTS:',TEXT1 ,'1',TEXT2, TOTAL1 ,TEXT3 , NOG01 , TEXT1 ,'2',TEXT2,TOTAL2, TEXT3 , NOG02) FORMAT( ,S(15) ,(2)((2) L,COM1 , COM2) ,P) ; END f* OF MAIN TASK TESTPR08 *f ; MODEND /* OF MODULE DIODETEST *f ;

1 . '1800 process supervisory program (PROSPRO/1800) ', 3. 'BICEPS summary manu al /BICEPS supervisory IBM no. H 20- 0473-1 (1968). control', GE Proc. Comp. Dept., A GET- 3539 (1969). 2. BATES, D. G., 'PROSPRO/1800', IEEETra nsactions 4. 'ATLAS abbreviated test language for avionics sys­ on Industrial Electronics and Control Instrumentation, tems' ARINC Specification 416-1, Aeronautical Radio Vol. IECI-15, No. 2, pp . 70-75 (December 1968). Inc. (June 1969).

119 5. METSKER, G. S., 'Checkout test language: an 9. 'INDAC8', Digital Equipment Corporation, Maynard, interpretive language designed for aerospace check­ Mass. out tasks', Fall Joint Comp. Conf., pp .1329-1336 10. 'PASl Prozess-Automationssprache 1 ', BBC (1968). Mannheim. 6. 'Bendix OPTOL programming system', The Bendix 11. BRANDES, J., et al., 'PEARL: A proposal for a Corporation, Teterboro, New Jersey (March 1968). process and experiment automation real-time 7. 'PLACE The compiler for the programming language language ', to be published by Projekt PDV, GFK for automatic checkout equipment', Battelle Karlsruhe. Memorial Institute, Columbus Laboratories, 12. DIJKSTRA, E. W., 'Co-operating sequential pro­ Technical Report AFAPL-TR-68-27 (May 1968). cesses', Programming Languages, F. Genuys (Ed.), 8. 'Official definition of CORAL66', Inter-Establishment Acadcmic Press, London (1968) . Committee for Computer Applications (February 1970) . CALLAWAY, A. A., 'A guide to CORAL programming', Royal Aircrait Establishment, Technical Report 70102 (June 1970).

120 Workshop on special systems and system features

Chairman: Dr H-J. TREBST Erlangen, W. Germany

The discussion centred on problems of testing gram in a different way. software, and the kinds of testing aids which can be offered, such as simulation of the environment H. The question of detecting faults is not neces­ in process control (either in the same or a differ­ sarily one of "Which level of language do we use?" ent computer), checks of source language lt is largely a matter of discovering when it is semantics and conventional debugging. possible to detect possible faults- at compile time or at run time. E. In checking against garbling of data, we have For example, consider the program kept a check sum on a block of data which is tested at regular intervals. This works well for {local a; a:=O; a:=a+1 , a:=a+1 } data which is either not changed much or usually changed in complete blocks, but is not so good where the comma denotes that the two statements when one or two words of a block may be chang.ed 'a: = a+l' are done in parallel. This is not deter­ more frequently than the rest of the block. ministic, I cannot imagine a situation in which this program is correct. Should we therefore Y. The method described by Professor Wettstein have it flagged by the compiler as containing a is a high-level analogue of the conditional semantic bug? assembly methods used for system generation by at least IBM and DEC. lt is very hard to debug L. There is considerable structure within a group these, because each possible configuration has to of interacting processes which may be deduced have an operating system adapted for it, and then from the programs. The testing of the inter­ checked on an appropriate physical configuration. actions between these processes is itseU a real­ For example, on our PDP-11 with RP02 disk, we time problem which cannot be truly tested in off­ assembled the adaptable disk handler for DOS line environment. The program preparation facili­ using the appropriate code for the RP02, and the ties for real-time work should include: resulting program in assembly language had an 1. Similation of interactions between pro­ error in it - obviously that had never been checked cesses. before the adaptable disk handler was distributed. 2. Flagging possible conflicts which could This does not mean that I doubt the value of arise at run time. adaptive operating systems, but that they are even These are analogous to automatic flow-chart more difficult to debug than non-adaptive operat­ generation for single process programs. ing systems. E. Debugging is never fully complete. We have V. Perhaps the very point of slipping from high­ to decide some possibly arbitrary criterion to level language to assembly language in debugging determine when to regard it as debugged. is that it forces the programmer to view his pro- Perhaps we can say it has reached this stage when the customer pays the bill.

121

CLOSING ADDRESS

This is now the end of another European seminar on real­ time programming. lt is the second of its kind and the idea of a relatively small group which can have a lot of good discussion seems to have proven successful. We could see that the general nature of the problems has not changed so much since the last seminar, wt it was remarkable how much emphasis was laid this time on the areas of testing and dewgging of real-time systems. I would like to point out that this time we could welcome some guests from overseas and it looks as if this seminar could develop into a fully international institution. I am also glad to tel1 you that the 'tradition' of this seminar will continue as there are plans to have the Third Seminar at the Euratom Research Establish­ ment at Ispra (Dr Metzdorf). In closing, I would like to thank all those who made this seminar possible, especially the Physics Institute for providing rooms and other facilities and my colleagues who helped in the preparation of this seminar. Last wt not least I thank all the participants for their efforts to come to Erlangen and for their contributions both in paper and discussions.

123

AUTHOR INDEX

BAUMANN, R., Interrupt handling in real-time control systems 46 BLANCHARD, Ph., Simulation du deroulement logique de programme de commande de spectrometres � neutrons 91 EICHENAUER, B., Real-time programming using a real-time language of intermediate level 115 FROST, D. R., Experiences with languages for real-time programming 9 HAASE, V., Which programming languages for minicomputers in process control? 19 HAMBURY, J. N ., Software aspects of the 'UMIST' hybrid 70 HAWORTH, G. McC., Process scheduling by output considerations 75 HEPKE, G., 'CALAS70' - a real-time operating system based on pseudo- processors 81 HERBSTREITH, H., A dynamic adaptive scheduling scheme for a real-time operating system 84 HEYWOOD,P. W., standard software versus high-level languages 15 HOWARD, V. J., An implementation of the assembly language and program assembler for a virtual 'CAMAC' processor 99 HUTTY, R. C., standard software versus high-level languages 15 LANGSFORD, A., An implementation of a virtual 'CAMAC' processor 96 LE DEBT, Ph., Simulation du deroulement logique de programmes de commande de spectrometres a neutrons 91 MITTENDORF, H., Efficiency of programming in higher-level languages 29 MUSSTOPF, G., The influence of the structure of high-level languages on the efficiency of object code 23 PYLE, I. C., Basic supervisor facilities for real-time 65 Q UILLIN, W. E . , System software real-time testing aids 106 ROST, H-P., Description of operating systems in terms of a virtual machine 43 · SCHOMBERG, M. G., Choosing a standard high-level language for real- time programming 53 SEDMAN, E. C., Testing and diagnostic aids for real-time programming 112 STENSON, J., Use of high- and low-level languages in a real-time system 57 TAESCHNER, M., Simulation du deroulement logique de programmes de commande de spectrometres a neutrons 91 WARD, P., Choosing a standard high-level language for real-time programming 53 WETTSTEIN,H., Adaptive operating systems 39 125 J. J., ,: t

EDITORS

IAN C. PYLE, MA, PhD (Cantab) has been wo rking with computer software since 1956, particularly concerned with programming systems (Hartran on the ICL Atlas Computer) , mu lti -access sys­ tems (HUW on the IBM 360 computer at Harwel l), and multi-compute r command and control systems . He is now Professor of Compute r Sci ence at the University of York.

PETER ELZER, MA (Erlangen) has been working with computers since 1966 , at the Phys ics Insti tute of the Univers ity of Erlangen. His early werk concerned the devel opment of a programming system for appl ication to nuclear phys ics experiments. He was one of the initiators of the PEARL project and is now leader of a PEARL implement team at the Physics Insti tute. Since 1971 he has now been invol ved with the LTPL project, of wh ich he is now the European Chai rman.

TRANSCRIPTA BOOKS