Linking and Loading

Like many systems, Nemesis separates the notions of linking and loading: linking is the process of resolving internal references within a chunk of object code, while loading is the business of relocating it and installing it in the address space of a Nemesis system. The model of linking and loading adopted in Nemesis needed to:

• solve the addressing issues inherent in a single address space operating system.
• deliver high performance at runtime, and
• allow fine-grained sharing of program text between protection domains.

Our solution is centred around the concept of modules. A Nemesis module is a self-contained chunk of code. It has no unresolved symbols or mutable data, and when loaded is potentially executable by any domain. All code in Nemesis (with the exception of the minimal assembler kernel) is part of some module.

The resulting programming model is one of ``objects'' which export multiple interfaces, each of which is identified by an address. Every call across an interface (in effect, any call across a module boundary) must pass the interface address as a closure. Objects per se don't have types; their interfaces do. In this way the notions of type and class are separated: the type of an interface is the set of operations it supports, and the class of an object is its implementation, which depends on the module that implements it. One way to think about modules is as CLU clusters ([]), except that modules can have no ``own'' variables since they are shared read-only between all domains.

We have found programming in this way is actually quite natural in stylised C or C++, especially with Middl compiler tools to generate the boilerplate. There is also design work under way to produce a language which compiles naturally down to C, but which maps very closely onto our computational model and provides more type safety and compile-time protection than C++ or C.