The purpose of this brief note is to mention some problems of core store access and addressing as a preliminary to a longer planning document no. 4 containing a more detailed analysis of software and hardware points related to our machine and supervisor.
There are two quite separate problems, and it is important to distinguish them clearly.
In the first case, we regard each user program as notionally a contiguous block of store (i.e. the programmer thought of it like this) with addresses running from 0 to some suitable N. It makes an online system much easier if user programs do not have to reside in a physically contiguous area of core, even if a contiguous area can be physically moved around using base-and-limit hardware. It is desirable to be able to bring into core only those parts of a program which are actually needed, only to rewrite to backing-store those parts which have actually changed, and so on. This line of thought leads naturally to page address register hardware.
In the second case we are concerned with the relationship between a user program and system programs or subroutines which are obeyed on its behalf. In what scheme of addressing are such routines written? Do they reside on the user's core which is temporarily extended; if so do they always reside at the same relative address or must they be written relocatably? If they are written as pure procedures in order to avoid having multiple copies, where do they find working space? How do they address it, bearing in mind that the swopping procedure may dump it and bring it back to somewhere else? Can working space be allocated economically, since such routines often require only a very little (e.g. 64 words)? Can such routines really be written as ordinary object programs, or must there be special restrictions which apply only to them? Is it reasonable to let such programs work without hardware protection of other users' store, if this simplifies things? Attempts to provide a satisfactory answer to these questions lead naturally to what in the GE645 is called the segment system.
The present purpose is to suggest that any scheme, whether software, hardware, or a combination, which does not give some answer to both of the two major aspects of the core store problem will be embarrassing to an on-line time sharing supervisor.
RMN
29 June 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: 2. Some notes on the
general characteristics of the proposed I/O system, RMN, 22 June
1965
Next Planning Document: 4. Software problems of core
space allocation and addressing associated with object programs,
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