This document illustrates the problems mentioned in Planning Document 3 by considering the present hardware/software configuration of Titan and the kind of new facilities required for the organization of object programs in core store. Various software solutions to these problems are proposed and discussed. Alternative schemes which include some form of change to the hardware appear in Planning Document 5.
The existing hardware and software permits an object program to have just one region of core store. This region must be basically consecutive although it is possible under certain circumstances for various blocks (512 words) within the region to be locked out and allocated for different purposes. In general, however, this cannot be taken very far for the following reasons:
As the system stands, it is easy in principle to add the mechanisms for several object program regions in core at the same time (multiprogramming); for regions to be dynamically shiftable (core compacting); and for regions to be dynamically dumped and undumped on backing store (so-called "swopping"). However, further extensions to permit the facilities proposed in Section 3 complicate the issue substantially.
The present system (plus the additional mechanisms) is adequate only when each object program core region corresponds to an independent object program; which implies that all common supervisor and system routines must be implemented under the SER system. To enable an expanding system, this latter point is unsatisfactory for the following reasons:
It is highly desirable that certain applications should be implemented as object programs. Basically, these are supervisor and system operations (particularly on-line system operations) which would benefit substantially by running on Main Control with normal object program protection and using object program facilities. We shall refer to these generally as System Routines dividing them into two categories:
Under the present system (outlined in Section 2), System Programs are feasible, but would have to be implemented as separate object programs for separate activities. This, for example, would require one copy of the console command program plus working space for each console in command status. System Subroutines in general would be loaded into a user's object program region as required, that is, into space provided by the user. At present, the IIT assembler and standard monitor routine are treated specially: the generalization of this forms the basis of Scheme C in the next Section.
The following explores various ways of implementing System Routines, ranging from crude and minimal software to sophisticated programming techniques. In doing this, it is hoped to illustrate the many aspects and general problems associated with object programs in core store.
This is minimal in its software requirements, being that described at the end of Section 3.
Object program regions are shiftable and dumpable: also, on undumping, a different core region may be used. (We shall call this attribute generally dumpable, as opposed to restrictively dumpable where the same core region must be used on undumping.) Full lockout protection is possible, and development as user object programs is simple.
System Subroutines must be written relocatably; their space must be provided by the user object program; they cannot be shared (i.e. pure procedures). System Programs cannot be shared, requiring separate copies for each activity.
Generally very inefficient core utilisation.
In addition to the single region, an object program is permitted to transfer control to (and from) a Supervisor Chapter (512 word segment of program). When this is done, the relativisation and limit control registers are switched to permit Main Control access to the Chapter. Thus, programs in one region may only communicate with the other region via b-registers or through special extracodes to access the region.
Core regions are shiftable and generally dumpable. Chapters can be shared, and mechanisms exist to avoid dumping in these cases. Programs are relocated by hardware; full lockout protection is possible; development as user object programs is not difficult.
System Subroutines can only access the user's object program by extracode, and also, if they are to be shared, working space must be located in the user's region and also accessed by extracode. This would result in certain extracodes being unavailable to shared routines (including some important input/output functions). System Programs have similar working-space access problems whenever they are shared.
Sharing is possible, but at a cost of very slow working-space access (of the order of 15-20 instructions).
This is an extended form of Scheme B enabling better communication between core regions by removing hardware protection and by making object program core space non-shiftable and only restrictively dumpable. While System Routines are in operation the hardware relativisation register is set to zero, and the lockout mechanism is used only to protect blocks involved in backing-store transfers. This implies two things: System Routines must be written in relocatable form, and they must guarantee only to access permitted regions of core store. In this scheme, System Routines might be permitted to have any number of core regions, although it must be remembered that each such region is neither shiftable nor generally dumpable.
System Routines may be shared, and working space access is fast. Development as user object programs is easy in principle.
All object program core space (with the possible exception of space containing shared programs only, i.e. no working space, tables, etc.) is non-shiftable and restrictively dumpable while System Routines are being executed. This would be a handicap to job scheduling and core allocation, and could result in inefficient core utilisation. Complete hardware protection is only available while System Routines are being developed as user object programs.
Sharing is again possible, but in this scheme the cost is inefficient use of core, and the need for System Routines to be written and developed only with great care, and possibly only by highly trained personel.
This is basically the same as Scheme C, but attempts to enable object program space to be shiftable and generally dumpable. Implementation has a number of complexities, and System Routines would be subject to some programming restrictions. System Routines access each region of core via one or more particular b-registers, these b-registers being known to the central supervisor routines, and updated by them whenever space is shifted and undumped.
System Routines may be shared, working space access is fast, and core space is shiftable and generally dumpable. Development as user object programs is possible.
No hardware protection. Certain input/output and backing-store transfer extracodes would still be difficult to organise if not impossible. The central supervisor space allocation and control routines would have considerably more work to do, with a consequent loss in efficiency.
System Routines would be difficult to write and certain essential facilities might not be available.
The schemes described above are in no way complete, but appear to be reasonably exhaustive of the problems involved and the various solutions that can be found for each of them. Variations are possible, of course, indeed have been considered, but none were found which would significantly improve the situation. Thus, with the present hardware configuration, we conclude that there are serious limitations on the implementation of System Routines as object programs.
DFH
2 July 1965
Copyright © 1965 University of Cambridge Computer Laboratory. Distributed by permission. Thanks to Barry Landy, Roger Needham and David Hartley for giving permission to distribute these documents. Thanks to Barry Landy for lending me the paper document from which this was scanned. Any typographical errors probably arose in the course of OCR.
Previous Planning Document: 3. (Untitled: preliminary
to number 4), RMN, 29 June 1965
Next Planning Document: 5. Views of possible
hardware alterations associated with object program core space
allocation and addressing, DFH, 2 July 1965
Return to Cambridge Supervisor Planning Documents
Return to CUCPS TITAN page
Return to CUCPS home page
Return to University of Cambridge home page