Single Address Space Issues

 The recent resurgence of interest in single address space systems has caused people to rediscover many naming issues which have been obscured by the almost ubiquitous use of C, C++ and UNIX-like operating systems.

In particular, being able to assume that a program has the whole address space to itself means that in C or C++ the execution environment for any procedure call is generally the sum total of data in the program. Aside from encouraging poor programming abstraction, this is disastrous in a single address space.

The naïve solution to this problem is to simulate per-process address spaces by keeping around a pointer (sometimes in a dedicated processor register) to a per-process data segment which contains most of the program state. Apart from being a throwback to the earliest days of multiprogramming, this has a number of disadvantages:

• The granularity of code sharing is very coarse: all the code constituting a program must be aware of the structure of the data segment. This means in practice that either you can only share text at the level of entire program binaries (as in UNIX), or every component of loaded code must assume the same format of data segment, which is absurd.
• To regain one of the main advantages of a single address space, namely that one can pass pointers between processes, there have to be two classes of pointers: both conventional absolute addresses and offsets from the start of the data segment ([]). This is unacceptable.

Clearly a better approach is required. The problem is really only one of explicitly specifying the calling environment to a procedure.