Support for special user level programs

All of the special purpose programs described in Chapter 5 were supported as intended. The SCOPE system simulator ran as the first user level subprocess, with its user as a direct descendent. The ECS system contained a special feature which generated an error whenever cell 1 within a subprocess field length became nonzero. (This is the form of a user call in the real SCOPE system.) The SCOPE simulator subprocess intercepted this error, and when called, the user subprocess would be in its Full Path. Thus the SCOPE simulator would have direct access to the user program's memory. The debugger (most of which existed in the command processor) gained access to the local memory and C-list of a subprocess through the Bead Ghost, a small subprocess which was the immediate ancestor of the user subprocess. (As in the case of the SCOPE system simulator, this access was provided by the Full Path.) Both the SCOPE system simulator and the debugger gained access to a subprocess local data through the Full Path. I feel an alternative to the Full Path was desirable. The full path was a device which would permit the memory of a subordinate program to appear as an extension of the memory of a more powerful program, e.g., a user program running under the SCOPE simulator or the subject program of a debugger. An unexpected effect of the full path was to force an unnatural division of system programs into two parts, one which had access through the full path to a subject program, and a second larger part which did not. Actual references to the memory of the subject program were infrequent, and would have been adequately supported by a special virtual instruction. In fact, the division of system programs into two parts could be thought of as an attempt to simulate such an instruction. However, the map facility made such a virtual instruction difficult to implement directly in the ECS system. In Chapter 20 we discuss other problems with the address map facility, and propose an alternative.