In the Monads systems very long virtual addresses (conceptually with up to 128 bits) were used for two related purposes:

• to locate a module on the basis of a module capability (e.g. when used as an operand for an inter-module call), and
• to address the individual memory segments associated with a module.

Long virtual addresses cannot be assumed to be available for SPEEDOS systems, and in practice they are not available in the Pentium system used for the first implementation. This restriction requires some modifications to the Monads techniques for handling module capabilities and for addressing modules.

The unique identifier of a module stored in a Monads module capability consists of an address space number in the persistent virtual memory, which may be distributed. This long address space number can be concatenated by the Kernel with an offset within address space to produce a full byte virtual address and thus address the module (e.g. information in its red tape). If the appropriate page is not in the local main memory a page fault is caused (as usual) and the page fault routine locates the module by interpreting the address space number as is described elsewhere. Although this simple technique cannot be used in SPEEDOS the module can still be located in the distributed virtual memory by employing the technique used in the Monads page fault handler, but as part of the execution of an inter-module call.

The next stage is for the Kernel, and thereafter the user, to be able to address the segments of the module. In Monads these could in principle be held in many different address spaces scattered throughout the virtual memory. This is no longer possible in SPEEDOS, but fortunately it is also not necessary. Because all modules in SPEEDOS, as in Monads, have a single uniform structure, their addressing requirements are well-defined. In particular a module must be able to address the following kinds of segments as it is active in a process:

• file (i.e. persistent data) segments;
• code segments;
• local data on the stack;
• local data on a heap;
• parameters received from its calling module;
• parameters to be passed to a destination module.

These are held in the following kinds of address spaces:

• a file address space,
• a code address space,
• a stack address space (which holds the local and both kinds of parameter segments), and
• a heap address space.

At any individual point in the execution of the process only four actual address spaces need to be addressable. For example the code of a module may actually be spread over several address spaces, but these need not be addressed concurrently; at any point the Kernel is aware which of the address spaces is needed.

Consequently the Kernel can organise the addressing environment of an active module into four address spaces. For example in the Pentium a linear address, which is a 32-bit paged virtual address, can be used for this purpose by treating it as a 2 bit address space selector and a 30 bit offset within address space. Thus the information held in any of these address spaces can individually have a maximum length of 1 Gigabyte.

It is the responsibility of the Kernel to ensure that the correct pages are mapped into the appropriate addressing ranges of the processes at any point in time.