A virtual memory organisation for minicomputer process control software

Automatica, Vol, 9, pp. 549-559. Pergamon Press, 1973. Printed in Great Britain.

A Virtual Memory Organisation for Minicomputer Process Control Software Une Organisation de Mrmoire Virtuelle pour les Circuits de Contr61e de Procdd6 de Mini-Ordinateurs Organisation eines virtuellen Gediichtnisses f'tir die Software eines MiniprozeBrechners O p F a H H 3 a u H ~ B H p T y a J I ~ , n O ~ IIaM~ITFI dI3"l~I M a T e M a T I , IqeClgOFO o r e c n e q e H H ~

ynpaB.rm~omnx MHHH 9BM JAMES D. SCHOEFFLER~" and LEE ROY B R O N N E R t

A software system employing paged virtual memory techniques permits minicomputer process control application software to be essentially maehine-size independent and capable o/'economie implementation.

Summary---Thewell known techniques of paged virtual memory provide an attractive base for the organization of process control software because the package can be organized as though a large memory were available but only those pages actually being used at any time need be present in the limited minicomputer memory. Such hardware is not available in minicomputers principally because of their limited word length. A software system for process control applications is implemented which takes advantage of virtual memory but avoids the inefficiencyinherent in interpreting every address as a virtual address by partitioning the application programs intomodules which reside on single pagesand use normal addresses for intra-module references. External references only are interpreted by the virtual space executive. Experimental results indicate that the system is efficient and attractive for this application.

when the data is referenced by its virtual address In this system, both the process data, i.e. all data and application files, and control programs for the particular application reside in a virtual space which is realized on one or more bulk storage units in the system. Through a paging mechanism, an application program can access any program or data file it needs in the virtual space as though the entire space were in core. Virtual memory is a well known technique and has been implemented in some large computers for many years. Unlike these systems where every address in every instruction is a virtual address, the proposed software system uses virtual addresses only in transferring control between modules and in explicit references to data items separate from the programs. By organizing application programs into a set of small modules which can reside on one page of variable size, normal hardware addressing modes can be used. Thus the software utilizes the full speed capability of the individual machines. Programs are not interpreted. Explicit virtual address references to seperate data and program modules are implemented by standard subroutines, compatible with high levellanguages. One approach to the implementation of this software system is presented in detail. Experimental measures o f efficiency and overhead are presented. One of the most economical approaches to process control software problems in the past has been thepackage concept in which an application is defined and a software system created for a given

INTRODUCTION THE objective of this paper is to describe a software system organized around a virtual addressing scheme, termed a virtual space, which permits minicomputer process control application software to be essentially machine-size independent. A virtual addressing scheme is one in which blocks of data are assigned addresses in a large address space, the virtual space, plus a mechanism for translating virtual addresses into physical memory addresses *Received 18 September 1971; Revised 28 August 1972; Revised tO January ! 973. The original version of this paper was presented at the 3rd IFAC/IFIP Conference on Digital Computer Applications to Process Control which was held in Helsinki' Finland during June 1971. It was recommendedfor publication in revised form by Associate Editor H. A. Spang IIl. tSystems Research Center, Case Institute of Technology, Case Western Reserve University, Cleveland, Ohio. 549

550

JAMES D. SCHOEFFLERand L~E RoY BRONNER

configuration which effectively supports all aspects of the application, including data acquisition, control, operator communication, and data base management. Examples include direct digital control packages and sequencing control packages [1, 2]. The user of such a package not be concerned with debugging the basic software, but rather supplying specifications on his particular problem which in effect merely supplies data to internal tables in the program. Three important advantages have been gained from this approach: complex control systems can be implemented with a minimmn of user software effort; the control system can be easily modified as the process changes without reprogramming; and the form of the input data is self-documenting [2]. Extending this type of software to minicomputers used for process control and other on-line applications is difficult because of the variation in configuration and size from application to application. The objective of this paper is to describe an implementation of a software system organized around a virtual addressing scheme, termed a virtual space, which permits process control application software to be essentially machinesize, independent and capable of economic implementation in minicomputers. Any real time system necessarily involves certain tasks which are time critical, that is, must be done exactly at the right time or rapidly in response to some event. The conventional solution is to provide core resident programs for such time critical tasks. Less critical tasks or very large computing tasks which are not core resident usually lead to the most complex part of the programming j o b - - f o r example, operator communication, updating of large data bases, etc. These involve many programs and large amounts of data which must be loaded into core from bulk to be referenced or executed, interrupted when high priority tasks must be carried out, etc. It is in these tasks involving complex programs, overlays and data bases, that the cost of realtime systems programming lies. By implementing this less time-critical set of programs and data bases in the virtual space, much of the machine dependence and programming complexity is removed at the expense, of course, of slower response time. Thus by partitioning an application into the critical part, which must always be core resident, and the less critical part, with respect to needed response time, it is possible to implement large applications in a very small machine. This approach is particularly well suited to operator communication, maintenance of direct-digital-control files, graphical console programs and files, and supervisory control packages.

The specilic advantages of this approach lbr process control software include: (1) The division of the virtual memory into blocks called pages implying that only the small part being currently referenced or executed need actually be in core at any time.

(2) The ability of the minicomputer to access any program or data file it needs in the virtual space as though the entire space were in core. Main memory space and response time can betraded off in a given application since response time of the virtual memory system depends directly upon the number of pages kept in core at any time. (3) The use of application programs which do not include blocking and buffering factors, physical location of data, etc. and thus are simpler and less costly to develop and maintain and moreover applicable to different size systems. (4) The great simlification of application programs which are large and access large data bases because overlays of programs and data need not be explicitly designed by the application programmer but handled automatically by the virtual space software. Virtual memory concepts and hardware have been known for at least 10 years but are not yet available in minicomputers used for process control applications. The software system discussed in this paper makes use of these well known concepts in order to gain their advantage for process control application but without introducing the large inefficiency which would result from straightforward software simulation of virtual memory on a machine without the supporting hardware. In particular, the system described takes advantage of the fact that process control application programs, such as operator communication, updating of files of instruments, etc. can be divided into a number of small modules or routines and separate data bases. Each routine resides in the virtual memory and executes at normal speeds with full machine efficiency because all references to data and labels within the module do not use virtual addresses. Only references to seperate data bases or calls for branches to other modules use virtual addresses which need to be software interpreted. Data references and program branches are handled by special routines, carefully coded to make the virtual space software system efficient to use in practice. A complete implementation has been carried out and studied and the results are reported in this paper.

A virtual memory organization for minicomputer process control software VIRTUAL MEMORY

Virtual memory was first introduced on the Atlas computer in England in 1961 [3]. The objective here was to eliminate the distinction between very fast but limited size core memory, slower drum memories, and much slower and larger disk and tape memories, by providing a very large virtual memory or address space which appears as fast incore memory to a programmer or user but which in fact resides in the slower bulk memories. At execution time, an instruction calling for some virtual address is subjected to an address translation process which calculates the actual core address from the virtual address, assuming the desired data is actually in core at the time, or traps to an executive system which brings the desired data into core if it is in bulk storage at the moment. Denning defines virtual memory as follows. Virtual memory is a system or set of addresses different from those provided by the hardware memory, together with a mechanism for translating program generated virual addresses into the correct physical hardware addresses [3]. The advantage of the use of virtual addresses in software is simply that a reference to a data item at some virtual address does not also imply where that data is actually stored either temporarily or permanently. The objective in the Atlas project was then tp permit data to be stored on disks and drums and brought into core only upon actual demand, thereby minimizing the amount of actual core storage needed. Figure 1 shows the organization of the virtual memory including the bulk storage device and address translation hardware.

Core of minicomputer Re~erences to data and programs via v w t u a l addresses

? /

One or more bulk storage u n i t s

I

~°°~::2,7'2' °n]

Large storage area f o r v i r t u a l space

FIG. 1. Realization of the virtual space system.

Virtual memories are usually paged so that one actually references an item by giving its page address and its relative location on that page. Within physical memory, a window or set of frames which can contain pages is maintained. Any page can occupy any frame and consecutive pages need not be contiguous in memory if both are present at the same time in memory. All references to data or program labels are via virtual addresses which are translated by the hardware into the corresponding physical location in core where that

551

address is at the present, and if the address is not present in physical memory, a swap of pages is made to bring it into memory. Since every reference is to a virtual address, efficiency of such systems is very dependent upon the task, its organization, its layout in virtual memory, and the software system implementing the paging. A lucid, thorough discussion of the state of the art of virtual memory hardware and software systems is given by DENNING [3]. It is for these reasons that virtual memory hardware is not available on minicomputers today and has not been applied to process control. However, software organized as though a large main memory were available and then executed in a small memory using the virtual address translation hardware would alleviate the important problem in process control software of making the large application software systems independent of the actual computer size or configuration. It is not feasible, however, to simply interpret or simulate the non-existent virtual memory hardware in a minicomputer. This would lead to every data and program label reference being a virtual address translated by software and would lead to a decrease in efficiency, an increase in execution time of more than I0 : 1 and as much as 100 : 1. This is intolerable in a realtime system where response time is critical as it is in many process control applications. The system proposed for minicomputer process control software and whose implementation is described in this paper retains the attractive features of virtual memory, namely a large virtual space which is paged and a window in main memory containing space or frames for some subset of these pages at any time. In order to maintain execution efficiency, process control programs and data are partitioned into a number of relatively small modules and data bases. Assuming most of the execution time is spent within modules rather than in transferring between modules, efficiency can be maintained by using conventional addressing within a module. That is, no data or label within the module is addressed via a virtual address. Virtual addresses are used for communication between modules and seperate data bases. This is significantly different from hardware implementation of virtual memory and succeeds only because the applications lend themselves to many small modules. Virtual addressing is then introduced by the programmer deliberately, and not by a compiler or assembler. It is necessary that any module residing in the virtual space be resident on a single page because consecutive pages are not necessarily contiguous in main memory, when they are both present there, and no hardware is present to trap references to

552

JAMES D. SCHOEFELERand LEE ROY BRONNER

addresses which are off the current page. Different page sizes are provided in the system to facilitate matching of program modules to appropriately sized pages. It must be noted that program modules which reside in the virtual memory may execute in unpredictable locations in memory since the page on which the module resides may be loaded into any available frame or slot in main memory when the module is called. Consequently, the module must be programmed so that it is position-independent. Relative addressing was used in the implementation discussed in this paper and could be used in many current minicomputers which provide this addressing mode. In others, base registers are available and the position-independence would be implemented at execution time by loading the appropriate address of the module into the base register before execution began using the routine used to branch to the module. A minicomputer which does not possess sufficient addressing modes to produce position-independent code cannot store program modules in the virtual space without significant modification of" the design described in this paper. The storage and accessing of data is still feasible however and may be useful in some applications such as graphic operator terminals. The desire to avoid fragmentation of memory by making pages, the size of data records, small is in conflict with the desire to have page size large enough to hold a typical program module. To avoid this conflict in the choice of page size, the virtual space is partitioned into sectors, each with a different page size. A basic unit of memory called an Allocation Unit (ALU) is defined, and all page sizes are taken to be an integral number of ALU. Each sector has the same number of pages, but the page size can be different in each sector. In the implementation discussed in this paper, eight sectors were provided with page sizes ranging ~'rom 1 to 8 ALU/page resulting in an 8 : 1 ratio of maximum to minimum page size. This range was sufficient for the process control applications considered. Three fields, referred to as sector, page and displacement, must appear in every virtual address. Figure 2 shows the allocation for a 24-bit word. Eight sectors of 256 pages each allow a total of 2048 pages in the virtual space. Since the lengths of the pages are actually equal to the sector number, in allocation units, it follows that the total length of

: 1..... :1

oge s ctorNo. rPogeo

Displocementin words on

22 21

o

8 7

Fie. 2. Format of virtual address in a 24-bit machine.

°

the virtual space is 36 x 256 = 9216 ALU Milch is much larger than is needed in most applications of minicomputers. In fact, only a few of the eight sectors would be used and space only for these would be allocated in the bulk storage. Allocation of fields in a 16 bit word poses more of a problem since the length of the virtual space would be limited to 64K words if the entire address were stored in a single word. Assuming an allocation unit of 64 words, this corresponds to 1024 ALU in the virtual space. II" only data is to be stored in the virtual space, a single sector is sufficient and the 64K size for a single sector of data is probabaly adequate for most applications. Otherwise, the sector number can be stored separately from the page-displacement portion ot the address with the virtual space executive assuming all references are to the current sector until notified otherwise. DESIGN OF A VIRTUAL SPACE SOFTWARE SYSTEM Software support for a minicomputer must include the necessary realtime programs, drivers and I/O control routines which are common to any computer system. In addition, there must be some mechanism for scheduling and controlling multiple tasks when they are permitted by the computer system, a basic executive capability. The software in a minicomputer may be organized as shown in Fig. 3.

Window into virtual space ( severa I pages)

virtual space n bulk

V i r t u a l space executive and contro I programs address translater + paging control Fast response criticot data acquisition and control programs Clocks, tEmers, interrupt control

Scheduler and task control

Normal minicomputer software

I n p u t / o u t p u t control programs

I n p u t / o u t p u t drivers

FIG. 3. Software implementation of V. S. system on a minicomputer. Those programs associated with data acquisition, control, the driving of peripherals attached to the minicomputer, any executive function, etc. are

A virtual memory organization for minicomputer process control software shown as permanent memory resident realtime programs. Because these programs require so much memory, there is a problem of squeezing in operator communication routines and the like. To link this computer through the virtual space organization requires software in addition to this system software but not in replacement of it. That is, a section of core, called a "window", is set aside for a small fraction of the pages together with a program, the virtual space executive, which maintains the window and controls the exchanges between main memory and bulk storage where the virtual space resides. The size of this window depends on the task, of course, and may be variable from computer, to computer and application to application. Thus, only that data which is common to the system as a whole and which resides in the virtual space, need be maintained and controlled by this portion of the software. Those aspects of on-line data acquisition and control, operator communication, and so on, which are best done with dedicated programs in the local computer, are still done exactly the same way. The linkage between on-line programs, programs inthe virtual space, and data stored in the virtual space, is discussed in the next section. Consider first the data structures which are used to define and implement the virtual space system. The most important area in core is the "window" into the virtual space. The main memory window is shown in Fig. 4. It consists of N basic units called slots equal in length to an ALU. The window is partitioned into two sections in this implementaton, each of which may contain pages from one sector at a time. In Fig. 4, the window contains pages from sectors 1 and 2. Since sector 1 has 1 ALU/page, each slot contains exactly one page. Sector 2 has 2 ALU/page so that each pair o f slots contains one page from the sector. Notice that if an odd number of slots

553

were allocated to sector 2, then one slot would be unused. Thus, the window may become fragmented whenever the sector number is not an integer submultiple of the number of slots allocated to that sector. The principle data descriptors necessary for the description and control of the system are shown in Fig. 5. The slot data descriptor is a two-dimensional array with one row for each slot in the window and with two columns. The first column contains the number of the page occupying that slot. Since pages of sector K occupy K slots, only the first of the K entries for each page contains the page number. The second column contains the time at which the page was swapped into the window. In effect, this establishes the "oldest" page in main memory which then would be swapped for the new page. Other algorithms to select the best page to swap may be more desirable [3]. Remembering that the virtual address is composed of a displacement, sector and page as shown in Fig. 2, the first step in the decoding process is to strip off the sector and page into seperate index registers leaving the displacement right justified in the accumulator. The sector transfer vector, illustrated in Fig. 5 and entered through the index register containing the sector number, points to either the page transfer vector for the particular sector if it is one of the two sectors in memory or else trapping to a routine which switches the sector currently in main memory. The contents of the sector transfer vector is a branch instruction to the corresponding page transfer vector. The trap Core descriptor I Starting slot First sector 2.Page size 3. M.T. slot # in memory 4 M i n i m u m t i m e ( M T 5.Fragment size

S l o t descri ,tJon Slot

Timber

Page No occupying t h i s S lot

Time this page was

Same

Swo pped

Same

I.Starting slot Second sector 2.Page size 3.MT. s l o t in memory 4 Minimum t l m e ( M T S Fragment size Dummy descriptor record for o i l sectors not in core Same

Sector 2 2 ALU/page

Sector trans#er vector (8 entries)

(2slots/page) Sector

boundary

Sector I

Link t o p o g e t r a n s f e r vector i f t h i s sector is currently in memory. Otherwise, link is to sector snap routine

2

Some

N slots

Sector

c',

I

FIG. 4.

Virtual memory window with example allocation.

First sector in memory

Same

/Second sector / in memory

Link to s l o t in v i r t u a l space window if t h i s page currently in memory, else link to page swap routine

Same

8

Same

Page transfer vector (I entr y/pa~

Some

Fla. 5. Principle data structures.

Same

Some

554

JAMES D. SCHOEFFLERand LEE ROy BRONNER

in the other positions are branches to the sector change routine. Details of the address translation would vary in other implementations. The page transfer vector entered through the index register containing the page number is the final step in the address decoding. For each of the two sectors in main memory, there is a transfer vector with one entry per page in the sector. The contents depend upon whether or not the particular page is actually present in memory in the window area. I f present, the transfer vector contents is an instruction which adds to the displacement, now in the accumulator, the starting core location where the page currently resides in main memory. If the page is not in main memory, the contents of the page transfer vector is a branch to the routine which swaps pages in memory. The address translation is summarized in Fig. 6. Vlrtua I ad.dress

I

1

Strip off page No Into index register I (X:)

1

F sector Strip off No into index register 2 (X2)

1

Pswop

(~ transfer vector indexed with X I

~.~ Page is in main memory Add address of beginning of page to displacement in accurnulQtor

l

Displacemer,t is left in occumulator

I!:II::I2oE(J

Branch to sector transfer vector indexed with X2

DO approprrate load, store, ar branch inst, uction using aboveGddre£s

memory space in the latter. Results of our ~ork indicate that the increase in efficiency of the latter more than compensates for the use of 2N locations for the two page transfer vectors. The memory descriptor contains live items for each in-memory sector, two in our implementation, and one for all others. As shown in Fig. 5, the first element contains the first slot in the window allocated to this sector. The second element is page size which is the number of slots or A L U per page and also the sector number. The third and fourth elements are used only when it is necessary to swap a page and contain the time of which the oldest page in this sector was loaded into memory and its slot number. These elements are determined by a search of the slot data structure by the swap routine. The last element of the descriptor is an indication of the fragmentation of the window due to the difference between the number of slots allocated to the sector and the number which can actually be used because of the multiple slots per page. In Fig. 4, for example, 16 slots may have been allocated to sector 1 and two slots to sector 2. If sector 3 is referenced and the system switches sector 1 for sector 3, the 16 slots would be allocated to sector 3 which requires three slots per page. Clearly only five pages can be present in main memory using only 15 slots. The left over area, one slot long, is indicated in element 5 of the sector descriptor and is used by the BMOVE routine which moves the boundary between sectors if more space is needed or if another sector in memory could use the unused space.

Sswap

i L I T h i s sector :s one otthe two in the window

FIG. 6. Virtual address translation. Notice that there is a fundamental design choice at this stage. I f the portion of the window allocated to a given sector can contain M pages and if there are N pages in the sector, one may either provide a data structure with M elements, a list of the pages currently in the window, or a data structure with N elements, the address of the page if it is in m e m o r y or a trap if it is not present. In the former case, each translation of a virtual address involves a search of M elements to find the address of a desired page. In the latter case, only a single location, corresponding to the page number desired, need be checked. This is a direct tradeoff between translation time in the former case and

USER SUBROUTINES TO ACCESS THE VIRTUAL SPACE A set of subroutines is provided to higher level language application programs for accessing programs and data in the virtual space. The first two routines P U T and G E T are used to retrieve or store a single word in the virtual space. Arguments are virtual space address and the address of a word of data in the calling program. For example, the format of the P U T routine used to store a word of data in the virtual space is " C A L L P U T (virtual address, data address)". The subroutines take care of saving and restoring of those registers needed by the virtual space executive program. Following register saving, the routines load the two arguments into registers and branch into the virtual space executive which performs the address translation shown in Fig. 6 and carries out the load or store instruction. The bulk of the time spent in these routines is in the saving and restoring of registers rather than address translation. Specific measurements are summarized in Section 3. Most references to files within the virtual space will not be to read

A virtual memory organization for minicomputer process control software or write an isolated word but rather write or retrieve a record, a sequence of words. The overhead involved in interfacing to the virtual space executive mentioned above is effectively by-passed through a second pair of routines for storing and retrieving a matrix, M P U T and M G E T . These are identical in purpose with P U T and G E T with the exception that any record or sequence of words stored on a single page of any sector may be written or retrieved by these routines. Arguments are : virtual space address of the first word, length and main memory address where the record is to be read or written. The data blocks are restricted to reside totally on one page, and this is error checked. In effect, the overhead per data item transferred is the overhead incurred in P U T or G E T divided by the number of items transferred. For records which occupy a significant fraction of an ALU, the overhead becomes negligible. Obviously application programs should be organized to take advantage of this fact. Note that the main memory address of the data item or array of items to be read or written may be within the virtual space window or be in permanent memory. Thus the user routines which access data in the space can be used by programs which reside in the virtual space. This follows because they execute as normal programs once they are loaded into a slot or set of contiguous slots in the window. Through the use of the M P U T routine, programs themselves can be stored into the virtual space and later executed. The requirement, as mentioned earlier, is that a program module must lie totally on one page, which can be several A L U depending upon the sector in which the page resides. A task can consist of a number of such modules which reference one another. Transfer of control from one to another, including the ability to return to a calling module, is the task of the routine B R A N C H . Transfer of control from one routine to another is either with or without a return. For these purposes, the branch routine has two entries, B R N C H M and B R N C H S , where M indicates a branch without return and S indicates the branch is to a subroutine from which a normal R E T U R N can be made. Implementation of B R N C H M is straightforward for the argument of the routine is the virtual space address of the desired routine. Hence it is only necessary to insure that the desired virtual space location is actually in main memory and then execute a normal branch to that memory location. The sequence is identical to that used in P U T and G E T except that the final instruction executed is a branch instruction rather than a load or store instruction. A branch with return is only slightly more complex. U p o n entering the branch routine, the return

555

address is known and can be saved in a stack within the branch routine. The instruction which transfers to the memory location within the window is a subroutine linkage instruction, such as a saveplace-and-branch, rather than a simple branch as above. Since the branch routine is resident in permanent memory, this return address can be used by any program in the virtual space as a normal return address, which returns control to the branch routine when the R E T U R N is executed. The branch routine can then retrieve the return address of the actual calling module from its stack and branch there. This scheme is shown in Fig. 7. A return address will always be a main memory address since all Subroutine A Call brnchs(B)

Return v i r t u a l address C

Branch routine Calculate and save return v i r t u a l address C

I J Stack i re*urn virtual

S a v e - p l a c e - branch B

R e t r i e v e ~ o p v i r t u a l addrees C Branch to C

Subroutine B IL

Return address

Return

Return by actual core address (not virtual address)

FfG. 7. Mechanism of virtual address branching.

programs use normal instructions which do not know of the virtual space software system. Consequently, the branch routine must transform all addresses within the window into virtual addresses before saving them because a page may be swapped out of its current slot in the window and later returned to a different slot and hence a different main memory address. This is a straightforward calculation since the branch routine saves the virtual address as well as the actual memory address within the window where the module is executing. Knowing the memory address of the return point and subtracting from it the memory address of the start of the module gives the displacement relative to the start of the

556

JAMES D. SCHOEFFLER and LLE RoY BRONNER

module. Adding this to the displacement field of the virtual address of the module then gives the return address as a virtual address. The main advantage of this scheme is that all program modules whether within the virtual space or main memory operate in the same way and use standard linkages. The only time virtual addresses appear is when control transfers from one module to another thereby minimizing the overhead incurred. Normally, control starts in a program in permanent memory, and the first transfer of control which uses the branch routines is a transfer into the virtual space. All further transfers are either to programs within the virtual space or a return to the calling program. No calls to other programs or subroutines outside the virtual space which might call modules m the virtual space, can occur. As a consequence, the first return address is always a main memory address and not a virtual address, and all subsequent return addresses must be virtual addresses. Thus, it is a simple matter f or the branch routine to stack the appropriate return address. The transfer of arguments is less straightforward. In most cases, this will be done explicitly within the modules by referencing addresses in the virtual space much like a Fortran C O M M O N area is used for interprogram communication. Modules which communicate this way transfer no arguments at all. However, it is desirable to permit argument transfer. The problem is, of course, that normal linkages are Call-by-Name and are implemented by transferring the memory address of the variable in question. This cannot be permitted in a software virtual memory system because of the lack of correspondence between a memory address and a virtual address. The calling program in which the variable exists may be swapped to a different slot in main memory for example. All arguments of routines which can be called by routines within the virtual space are passed through a stack contained in the branch routine. Thus, in effect, all these subroutines act as though they had no arguments at all as far as the linkage problem is concerned, and hence they are called by B R N C H S as above. Four user routines are available for entering variables on the stack and removing them. They are: WV--write value of a variable on top of the stack, RV---read value of a variable from top of stack, W N - - w r i t e virtual address of a variable on top of the stack, R N - - r e a d virtual address of a variable from top of stack. The two write routines push the stack before writing

and both read routines pop the stack after reading Thus, any routine desiring to transfer variables by value or name must put the appropriate values and addresses on the stack via these routines. Similarly, the using routines must remove them, thereby doing the linkage explicitly. The conversion of memory addresses to virtual addresses, necessary in the WN routine, is done by the same portion of the branch routine which transforms return addresses to virtual form. The net result of this arrangement is that subroutines can be contructed using normal Fortran or other higher level language facilities, loaded without modification into the virtual space with the M P U T routine, and executed by calling the branch routine. More efficient linkages can be constructed if the subroutines are written in assembly language of course. Moreover, any system can be a mixture of the two, thereby permitting the bottlenecks in an application package to be optimized without requiring assembly language coding of all routines. The user subroutines must be re-entrant, especially the Branch routines, if used by more than one program in a multiprogramming realtime environment. In process control application packages, this is usually found to be unnecessary in that applications such as operator communication are usually funnelled through a single routine. THE VIRTUAL SPACE EXECUTIVE ROUTINES The virtual space executive consists of only five basic routines: I N I T I L (initialization), SSWAP (sector swap), PSWAP (page swap), B M O V E ( b o u n d a r y move), and P T R A N S F E R (page transfer). The function of the initialization routine is to initialize all the data structures discussed above. The sector swaproutine is entered whenever a sectoris addressed which is not one of the two in memory. If the reference is from a program in the virtual space, the other sector is swapped. Otherwise, the sector not most recently referenced is swapped. The page swapping routine is entered from a trap in the page transfer vector when a referenced page is not in main memory. Three operations are performed. First, using information in the memory descriptor, those slots allocated to this sector are examined to find the one which should be swapped out of memory. Second, this page is swapped out of memory and the new page into memory using the P T R A N SFER routine. Third, the usage of the sector is examined to determine if the division between the two sectors is properly located. I f pages are being swapped too often a call to the BMOVE routine is made to attempt to increase the number of slots allocated to this sector, at the expense of the other sector of course.

A virtual memory organization for minicomputer process control software Calls for pages are made upon demand and control is not returned to the calling program until the page transfers are complete. This is in keeping with the philosophy of the virtual space software system which is mainly intended for the use of slow-response programs which require large addressing spaces. Of course, on-line realtime programs are multiprogrammed and interrupt this process as often as necessary to carry out tasks such as data acquisition. The page transfer routine, P T R A N S F E R , is a subroutine which calculates the appropriate bulk storage address for the page and carries out the transfer to or from the main memory. The last routine in the virtual space executive is BMOVE which is responsible for controlling the division of the slots in the window between the two sectors in main memory. The boundary is moved only upon request of the PSWAP or SSWAP routines and involves swapping several pages of one sector out of memory using P T R A N S F E R and reading in pages from the other sector. Each call to BMOVE adds only one additional page to the requesting sector so that the boundary does not move rapidly. E X P E R I M E N T A L RESULTS

To test the usefulness and efficiency of a virtual space system within an on-line environment, three implementations have been carried out during the past 4 years. The first involved only a single sector and only data was stored in the virtual space [4]. The objective here was to use the virtual space for the storage of large multiplylinked, in a list sense, data structures for graphic input and output purposes. The results indicated that on-line interactive operator communication with full graphics could be easily supported by such a system and that in fact the paging and swapping was invisible to the user because of normal user response time. The second implementation involved a package similar in overall design to the one described here [5, 6]. The objective was to build an automatic storage allocation package for large file usage. The package consisted of ten program modules each on a single 256 word page, and the entire virtual space served as the data base. The allocation routines were used in maintaining eight different page sizes, and detailed data structures, the sequential fixed size records, linked fixed sized records, and others were stored in the free space. The user requests or releases a record of a particular type and size and the routines return with the virtual space location. The total package was utilized to demonstrate that different page sizes did in fact contribute significantly to the performance of the system with little increase in complexity.

557

The third implementation extended and refined the system and is the one discussed in this paper. Although it is being used for both on-line computer aided design and interactive graphic communication with a process control system, only tests to indicate its efficiency, overhead and speed of response will be discussed here. References to data within a program is not through virtual addresses so that no decrease in efficiency of program modules arises. However, each reference to an item in the virtual space through the P U T or G E T routines involves some overhead. The total response time of P U T or G E T was measured and found to be 200 /tsec in a machine whose normal indexed instruction execution time is 4.8 #sec. This includes time to transfer to and from the routines, save and restore registers, as well as translate the virtual address and move the data. This figure does not include any swap time, if its use was necessary. Of course, if the data is not in main memory and a bulk storage access must be performed, the overall access time is determined by the seek and rotation time of the disk and is almost independent of whether the addressing is virtual or absolute. A much better measure of the efficiency of the system is the time required to access a block of data, for normally records are stored and retrieved rather thanisolatedsingle data items. Note that once a module retrieves a record it can reference individual items within that record by normal addressing without incurring the overhead of the G E T or P U T routines. The M P U T and M G E T routines provide the facility of retrieving a block of items whose length is less than one page long in. whatever sector the data resides. With a single call to the routine MGET, the entire block is transferred to an area within the users program where it can be addressed with normal non-virtual addresses. The use of the M P U T or M G E T routine to retrieve or write requires 50 /lsec per word which is only 1/4 that of a single word read or written with P U T and GET. This is due to the implementation of the matrix PUT and G E T routines. Since the record must reside on a single page, these routines first do an almost normal P U T or G E T to insure that the referenced page is in main memory and to convert the first virtual address to a normal physical address. Then the remaining items are transferred with a tightly coded loop. The net result is that the overhead associated with the routine is totally used in getting the first item. The overhead per word is then simply the overhead for one item divided by the number of words transferred. This time included all saving and restoring of registers, indexing and error checking. For anything but a very short record, the overhead becomes negligible compared to the advantages of the virtual addressing scheme.

558

JAMES D. SCHOE[:FLERand I_LE R o y BRONNER

Comparison of data transfers p r o g r a m m e d in a process control F o r t r a n language available indicated that M P U T and M G E T were more efficient and this is to be expected since the routines are optimized for their special task. Nonetheless, this is important because m a n y process control application programs are written in realtime Fortran. Time required for disk seek and rotate are large c o m p a r e d to the virtual space address manipulations with the result that the virtual space organization appears at least as efficient as other organizations which store data files and p r o g r a m files on bulk storage. In other words, the overhead becomes apparent only when the virtual m e m o r y system is c o m p a r e d to a tightly coded system implemented totally in main memory. F o r this reason, we recommend its use in packages as indicated in Fig. 3 where the portion o f the system which really should remain fully in main m e m o r y is tightly coded there and the other less eritical tasks, including the storage o f large files, graphic data structures, slow response program modules, etc. are stored in the virtual memory. The implementation in a 24 bit machine resulted in the following p r o g r a m sizes: (1) D a t a structures: 580 words. Notice that 512 o f these were the two page transfer vectors. (2) Virtual M e m o r y W i n d o w : 18 allocation units o f 256 words each =4608 words. We concluded that the size of the A L U should be reduced to 64 words for more efficient storage o f records on pages. P r o g r a m modules which often are o f 200 word size would then reside on pages in sector 4. (3) User. subroutines (PUT, M P U T , etc.): 360 words. (4) Virtual Space Systems routines: 600 words. O f the 600 words, the initialization required 274 words and is used only at the start. It was not later overlaid in this implementation as it could be. In summary, the total virtual space system occupied 6150 words in our current implementation. We anticipate removing the initialization routine and shortening the window to reduce it to slightly below 4 K which we consider a reasonable and desirable size for the application o f this system. We estimate that one m a n m o n t h would be required to implement the system on a different machine. CONCLUSIONS A software system suitable for process control applications has been described which uses the well k n o w n techniques o f virtual m e m o r y as its base but avoids the inefficiency inherent in interpreting every address as a virtual address. This involves the partitioning o f the application package into a

set of modules each of which resides on a single page o f virtual m e m o r y and uses normal addressing modes for references within the module itself. Only references to other modules and data separate from the p r o g r a m use virtual addresses which require interpretation by the virtual space executive. One implementation o f the software system is described in detail and experimental results presented. The objective of the above tests was to determine the penalty one pays for using virtual space addressing. The conclusions we draw are that: (1) References to isolated variables carry a high overhead, 200/~sec. (2) References to blocks o f data carry a negligible overhead. (3) lntermodule transfer time is small enough for applications intended. (4) The response time of the system is adequate for operator communication, large file usage, and lower priority tasks. REFERENCES [1] C. L. SMITH: Digital control of industrial process, computing surveys. 2, 211-242 (1970). [2] H. E. JORDANand J. D. SCHOEFrLER : Role of Minicomputers in Process. Control. TAPPI Engineering Conference Proceedings (I 970). [3] J. DENNING: Virtual memory. Computing Surveys 2, 153-190(1970). [4] M. PLINER: A Graphical Software Package for Interactive Man-Machine Communications, M. S. Thesis. Case Western Reserve University (1969). [5] R. H. SHERMAN;A File System for Computer Control Application Software, Ph.D. Thesis. Case Western Reserve University. [6] J. D. SCHOEFFLERand R. H. SHERMAN: Software Organization for Minicomputer Systems. Proceedings of the IFAC/IFIP, Symposium on Digital Computer Applications to Process Control (1971). R6sum~-Les techniques bien connues de m6moire virtuelle pagin6e fournissent une base attrayante pour l'organisation de circuits de contr61e de prccSd6 parce que rensemble peut &re organis6 comme si une grande m6moire 6tait disponible, mais seules les pages n6cessaires au moment suffisent /I la m6moire limit6e du mini-ordinateur. De tels circuits ne sont pas disponibles dans les mini-ordinateurs surtout en raison de la longueur limit6e de leurs roots. Un syst&mede circuit pour les applications de contr61e de proc6d6 est mis en usage qui prend avantage de la m6moire virtuelle mais 6vite l'in6fficacit6 toujours pr6sente dans rinterpr6tation de chaque adresse comme adresse virtuelle en s6parant les programmes d'application en modules qui rgsident sur des pages simples et utilise les adresses normales pour les r6f6rences intra-module. Seules les r6f6rences externes sont interpr6t6es par l'ex6cutif d'espace virtuel. Les r6sultats exp6rimentaux indiquent que le syst~me est efficace et attrayant pour cette application. Zusammenfassung--Die wohlbekannte Technik des paginierten virtuellen Ged/ichtnisses ist eine attraktive Grundlage fur die Organisation der Software bei der ProzeBkontrolle, weil die packung so organisiert werden kann, als ob ein groBes Ged/ichtnis verftigbar w/ire, aber nur die Seiten tatsfichlich benutzt werden, die zu irgendeiner Zeit in dem begrenzten Minicomputer-Ged/ichtnis vorhanden sind. Solche Hardware ist in Minieomputern prinzipiell nicht verfiigbar und zwar wegen ihrer begrenzten Wortl/inge. Verwirklicht wurde ein Softwaresystem ftir Anwendungen der

A virtual memory organisation for minicomputer process control software ProzeBsteuerung, d a s v o n d e m virtuellen Ged~ichtnis profitiert, aber die m a n g e l n d e Effektivit~it vermeidet, die d a m i t u n t r e n n b a r v e r b u n d e n ist, d a b iede A d r e s s e als eine virtuelle A d r e s s e interpretiert wird. D a s geschieht d u r e h U n t e r teilung der A n w e n d e r p r o g r a m m e in Baueinheiten, die sich a u f einzelnenSeiten befinden u n d f a r die B a u s t e i n e n o r m a l e A d r e s s e n beutzen. Experimentelle R e s u l t a t e besagen, d a b das S y s t e m in Hinblick a u f die A n w e n d u n g w i r k s a m u n d a t t r a k tiv ist. P e 3 m M e - - X o p o t u o H3BeCTHag HOCTpanH~tHaa B~pTyaflbHa~ IlaM~lTb o6~crleqnBaeT OTJIHrIHe BO3MOTKHOCTH~JI}l o p r a ~ H3aI.~H MaTeMaTHtleCKOrO o6ecHe~IeHMIt ~JI~I yIllgaBJIeHHIt HpOH3BO~CTBOM e 3TOM CJtyztae IIaKeTbI MOryT 6bITh opraHH3OBaHbl Tal¢~ Kai< 6y~To B pacrlOp~DKeHHH HMeeTCIt

559

naMaTI, 6 o m , m o r o o6~oeMa B TO )Ke BpeMa B mO60~i ~annblfi MOMenT I4Cl'IO.rIb3yIoTc~[ TOJIIaKO Te cTpanm.u,t, rOTOpbIe ~OYDKHbl 6bITB pacnono~eHbi B He6oYrbInofi naM~ITH MIIHH 9 B M HO~O6HOe o6opy)ioBantle llpltttlBIIIltaJ~HO He HMeeTcFI y MHHH 3 B M BC.rle~CTBHeorpanm~en~ofl n~mH~i CnOB y HnX Pa3pa6oTaHa C~CTeMa MaTeMaTn~ecxoro o6ecne~enn~ n n ~ ynpaBneHn~ npo~3BOnCTBOM, r o T o p a ~ o6nanaeT ~OCTOHHCTBaMH BHpTyaJIBHO~ IlaMgTtt. B TO ~Ke BpeMfl B Hei~ HeT Hy;~K,~bIHHTepnpeTllpOBaTl~ Ka~l(,/lbl~ a~apec raK BnpTya~bm,I~, B cny,~ae p a 3 6 ~ e n r ~ pa6o~mx nporpaMr~ Ha Mo21yn-a, pa3MetttaeMble Ha O~HO~ c T p a n n u e , n ncnom,3OBaHnn o6~,i,mux a~pecoB nnfl BnyTprl-MO~lynl,rIbIX o 6 p a t u emai~. T o n b r o BHelIIHHe o6pameHHa HnrepnpeTnpyroTcfl ynpaBn~iottte~ nporpaMMO~. ~)XcrleptlMeHTaJIJbltble pe3yabTaTt,I IIoKa3MBalOT, '-ITO CneTeMa BeCbMa 3qbqbeKTHBHa2I~lfl no~o6nblx npHMeneHn~.