Planning Document 4 discusses the problems associated with attempting to enable System Routines to be written as object programs; it is recalled that under present conditions, the various solutions were not attractive. Under the principle that some form of change to the hardware is feasible, this document discusses the various kinds of hardware alterations or additions which would be beneficial to System Routines and to the general organization of object program core space in a multiprogramming and multiaccess system.
The main requirement for System Routines is means by which a Main Control program may directly access two or more separate regions of core store. Assuming a need for core space to be shiftable, this essentially indicates that references to a region should be individually relocated, and possibly protected by hardware. For these purposes, something of the following nature could be useful. Two additional sets of relativisation and limit registers are provided, and come into use when reference is made via addresses of the form nJ1 and nJ2 respectively. (This would replace the present use of J1 and J2 addresses which has not been implemented in any existing system.) In this scheme, user object programs would operate with J0 addresses, System Routines with J1 addresses, and working space for shared System Routines would be accessed by J2 addresses. It is assumed that the basic unit of storage would remain at 512 words. An alternative, which is slightly less attractive softwarewise, might be for all addresses to be J0, and V-store controls which permit preselection of which region is to be used for instruction accesses and which to be used for operand accesses.
Even with a scheme of this nature, there remains the need for core space shifting in order to maintain several active programs in core simultaneously. This is certainly feasible to implement by software, but would be both time consuming and a complication to space allocation routines. At present, the latter are further aggrevated by the hardware ORing the relativisation register with address references. If instead, these were added, space allocation would be a good deal easier and space shifting reduced but not abolished.
For the complete abolition of space shifting, it appears that some form of Page Address Register system would be a solution. In a straight-forward scheme, it might also be possible to reserve high-order relative addresses for System Routines and their working space (as is done in Atlas 1), and the problems of separate core regions are mostly solved. The main problem arising, however, is in the unit of store addressed by each page register. If the unit is small, a large number of registers are required and the hardware cost is excessive; on the other hand, if the unit is large, the amount of space wastage becomes a serious factor. This dichotomy appears insoluble in the context of the desire for system routines and working space to be organized as object programs. It is very important to realize that in general, these require small amounts of space associated with each of many activities. Typically, this is often as little as 64 words for working space, and 512 words for programs.
In view of the above considerations, the following is a scheme which would appear to be very suitable for the planned Cambridge Supervisor, while it is hoped that it is not excessively costly. No doubt many of the figures quoted could be amended without significant loss of facility.
Assuming a 64K store, there are 16 page registers which are accessed by all J0 addresses. Each relative address is taken modulo 64K and each page gives access to any unit of 4K. Each page register has its own "locking" bit and possibly, as a luxury, "use" bit(s). If the store is subsequently extended to 128K or more, additional page registers are not essential if it is agreed that the maximum user core region is 64K: a reasonable assumption in the context of a multi-access system (i.e. larger programs could be segmented).
There are 4 (separate) page registers which are accessed by all J1 addresses. Each relative J1 address is taken modulo 2048 and each page gives access to a unit of 512. Each page register has a "locking" bit and perhaps "use" bit(s) although the latter are not essential. This addressing scheme would be used for System Routines, and a total addressable region of about 2K makes it feasible to implement loaders and the IIT assembler in this way. Buffers for certain system transfers from backing-store would also use this scheme.
There are also 4 more page registers accessed by all J2 addresses. Each relative J2 address is taken modulo 256 and each page gives access to a unit of 64 words. There are locking bits as before but probably no need for use bit(s). This scheme would be used for System Routine working space, and would in particular enable them to gain direct access to pieces of SER working space.
There are two alternatives for J3 addresses (which are forbidden to object programs, and used for SER's). Either J3 is treated as J1, or there is a single page register accessed by all J3 addresses. A J3 address is taken modulo 512 and the page register gives access to a unit of 512 words. No locking bit is required, and use bit(s) are not essential.
With this scheme, the existing hardware lookout registers r3 and r4 might be retained to enable an individual 512 word unit in the J0 addressing system to be locked. Similarly, certain features of r5 might be retained.
A characteristic of this system is that only small units of core space would need to be shifted, and then only on relatively rare occasions. The inclusion of use bits would save unnecessary dumping.
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 (and confirming that the marking of this document as Confidential no longer applies). 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: 4. Software problems of
core space allocation and addressing associated with object
programs, DFH, 2 July 1965
Next Planning Document: 6. A Proposed File
Dictionary System: I - External View, DWB, 28 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