An on-line version is also
available.
An on-line
version is also available.
An on-line version is also
available.
It is desirable to port Nemesis to platforms which are inexpensive and widely available. A key part of this workpackage is thus the development of two new ports of Nemesis. This workpackage must also provide support to the large group of partners to work with Nemesis independently through operating system maintenance work, delivering documents (user manuals) and debugging facilities. Finally, two key extensions of Nemesis will deliver a Virtual Memory management system, and functionality to emulate Unix on top of Nemesis.
The majority of work in this workpackage is being done here in Cambridge and at Glasgow. It comprises the following tasks:
(Cambridge)
Nemesis was designed as a portable operating system, and can in principle be ported to any modern architecture. A preliminary study of porting Nemesis to the Intel `86' architecture indicated that a port to this widely-available architecture is both feasible and attractive.
Options for the ports were as follows:
Chip source Chip architecture Implementation Intel 86 (Pentium) PC, PCI bus Digital AXP (21164) AXP/PCI board ARM ARM Risc PC ARM ARM Set-top box
We have committed to producing ports for the Intel Pentium and Digital AXP 21164. In addition, in an effort to demonstrate the utility of Nemesis to interested industrial followers of the project who include vendors of Set-top boxes, Risc PCs and other ARM-based platforms, we will undertake preliminary work for a port to one ARM based platform, and will report on the work undertaken in this area.
Currently, Nememsis runs on the following platforms:
Deliverables: Reports and software, as follows:
An on-line version is also
available.
An on-line
version is also available.
An on-line version is also
available.
(Cambridge and Twente)
Nemesis is a working operating system, but not one of production quality. There is some unevenness in the code of Nemesis, due to its implementation during the period when it was being designed; this, together with the fallibility of the authors, means that there are also bugs in the code. Pegasus II requires a stable basis to proceed.
The complex interactions of an operating system are such that only by use and observation do performance bottlenecks come to the fore. Furthermore, integration of new ideas and algorithms from the wider research community is necessary to keep Nemesis at the cutting edge. Continual enhancements to improve performance are seen as part of the systems maintenance task.
We will also undertake development of more satisfactory mechanisms of kernel debugging and profiling, in order to facilitate future support of Nemesis.
Deliverables: The task will maintain Nemesis' documentation, and the version of that documentation available at the end of the project will be delivered, as the then-current version was delivered at the end of Pegasus. In addition, the task will feed reports of its progress into the management system. Formal deliverables will be software and its documentation, as follows:
(Glasgow and Cambridge)
A comprehensive design for memory management within Nemesis was developed with the rest of the design of the system; however, that design was never implemented as a virtual memory system by reason of the pressure of other work within the project. Virtual memory of some sort is essential on any modern processor; the processors are designed in such a way that the operating system has to control the memory management hardware for programs to run at all. Nemesis currently controls the memory management hardware in a `null' way, though the null routines carefully conform to the specified interfaces.
For production use, a single-address-space operating system, such as Nemesis, must have virtual memory. On at least some processors, the virtual address space that the program observes is larger than the total amount of physical memory that can be attached to the processor; by its nature, Nemesis tends to exploit the whole of the virtual address space at different times in its operation.
The interfaces defined by Pegasus are to the generic service required of the virtual memory system. This task will implement the service behind the interfaces. The primary focus of the work will be on strategies to enable each application to control its own protection mappings. As with other aspects of the Nemesis architecture, this is provided to enable application specific virtual memory policies, with default policies implemented as shared libraries. Besides the obvious use for application paging and swapping strategies, such support can then be used for incremental garbage collection and direct support for "object swapping".
Deliverables:
(Glasgow, Cambridge and Twente)
Nemesis is a `single address space' operating system, whereas Unix is intrinsically a multiple address space system. The contrast has been a stumbling point for much existing research into single address space operating systems; the Pegasus project tackled the issue head-on by claiming that Unix functionality was not fundamental to the design of the system.
However, the marketplace requires Unix-like functionality: there is a huge body of Unix-compatible software that users have come to rely on, and Pegasus II must therefore confront Pegasus' early claims.
A preliminary design for Unix functionality within a Nemesis domain exists, employing the application-specific features of the memory management design that is to be implemented. This task will develop that design to the point of implementation.
The compatibility offered will be at the source-code level; it is not practical to offer binary compatibility. Furthermore, while the project expects to use one of the free-licence Unix implementations as a basis for the functionality itself, there is no intention to model the interfaces on any implementation in particular: rather, the aim will be to provide a system that is "as easy to port to as a native Unix implementation". (Such an aim was the intention of the experts who defined the Posix portable operating system interface standard.) It should be stressed, however, that emulation of a full Unix functionality is beyond the resources of the project, which will deliver Unix-like functionality which is sufficient to support for the majority of existing unix applications.
Deliverables: