Traditionally there has been a clear distinction between computational (short-term) memory and filestore (long-term memory). This distinction has been maintained mainly due to limitations of technology. Recently there has been considerable interest in programming languages and systems which support orthogonal persistence. In such systems arbitrary data structures may persist beyond the life of the program which created them and this distinction is blurred. Systems supporting orthogonal persistence require a persistent store in which to maintain the persistent objects. Such a persistent store can be implemented via an extended virtual memory with addresses large enough to address all objects. Superimposing structure and a protection scheme on these addresses may well result in them being sparsely distributed. An additional incentive for supporting large virtual addresses is an interest in exploiting the potential of very large main memories to achieve supercomputer speed. This paper presents hardware and software mechanisms to implement a paged virtual memory which can be efficiently accessed by large addresses. An implementation of these techniques for a capability-based computer, MONADS-PC, is described.

Neither low-level mechanisms such as semaphores nor higher-level mechanisms such as path expressions provide a simple means of solving synchronisation problems involving the scheduling of processes or classes of processes according to different priorities. This paper presents a new set of primitives which are easy to use and simple to implement. Their use is described in terms of the familiar reader–writer problem and the general scheduling problem involving arbitrary levels of priority with support for pre-emption and shared access by certain process classes. An efficient implementation, which reduces to a minimum the number of calls required to the process scheduler, is then described.

Traditionally, instruction sets have included separate instructions for manipulating different data types, such as integers and real numbers.A long-discussed but seldomimplemented alternative has been tagging, where the type information is stored adjacent to the data itself, rather than being inferred from the instructions.Over the years, several advantages have been claimed for tagging, including improving program reliability, saving memory, and facilitating a high-level language architecture.For computers that are not specifically oriented toward dynamically typed languages, we show that tagging fails to achieve these advantages completely, and that most of 'them can be better achieved by extensions of other mechanisms.

A stack-based instruction set which includes two-operand, one-operand and zero-operand instructions is proposed, and is shown to produce a more compact code and fewer instructions for evaluating assignment statements than one-operand and zero-operand stack instruction sets. If this instruction set is then extended to include two-operand memory-to-memory instructions, the combined instruction set also produces more compact code than a simple memory-to-memory instruction set, for a set of "typical" assignment statements weighed by the frequency of their occurrence in real programs. Finally various alternatives for optimizing the proposed instruction set are discussed.

A weakness in the reader priority solution proposed by Curtois, Heymans and Parnas for the problem of synchronizing concurrent readers and writers is described and an improvement is explained. The difficulties of solving complex synchronizing problems by using standard semaphore primitives, as illustrated by this example, lead us to propose that special-purpose synchronization techniques should be supported by a judicious combination of hardware/microcode and software routines. We then describe an efficient solution for the reader/writer problem which is easy to understand, to implement and to use.

It is proposed that semaphores should in some circumstances be extended by associating with each semaphore, in addition to the usual integer, a set (bit string). There are two separate uses for this set, which are considered separately and which can be implemented independently of each other. The first, the available resources set, has a bit identifying each resource controlled by the semaphore, which will indicate when the resource is free. When no resources are free the set may then be used to identify those processes waiting on a resource. The advantages and disadvantages of both sets are discussed, including the possibility of eliminating MUTEX semaphores from situations such as producer/consumer activities, and the possibility of entirely ‘automating’ (i.e. controlling by hardware semaphore instructions) the synchronisation and scheduling of processes.