The normal run-unit sharing process is performed automatically by the CP-6 monitor; it is essentially invisible to the users of a shared run unit, and requires no intervention by either the system operator or the system manager.
Programs are placed in shared status when users invoke them, and remain in this status until there is no further use for them.
Programming Considerations
Almost all programs written for the CP-6 system are capable of being shared.
Shared programs can acquire and release memory and DeBs, access files and issue all but a very few monitor service requests without having to take the program's "shared" status into consideration. A shared program can (if necessary) issue an MSUNSHARE monitor service request, which creates a new, unshared copy of the program's procedure on behalf of the user currently running the program.
Programs written in a high level language (FORTRAN, Pl-6, PASCAL, etc.) are generally very good candidates for sharing, as all executable instructions and constants generated by these languages' compilers are automatically placed in
"read/execute/no-write" memory.
Programs or subroutines which are being written in assembler (GMAP or BMAP) should be coded with data stored separately from procedure and without self-modifying procedure in order to take advantage of the auto-sharing process.
To ensure that a large, overlaid program can be shared in an effective manner, care should be taken when the program's overlay structure is designed.
Specifically:
• The program may have only one level of overlays; that is, an overlay cannot have other overlays subordinate to itself.
CE62-00 Programming Considerations 10-2
• The program shouLd not have a Large number of overLays at LeveL 1. Each programmer shouLd request that the system manager increase the SPAUTOSPACE entry in the TIGR deck to accommodate the Large programs. It is aLso important to note that not aLL overLays of an overLaid program which is shared need to be in memory at once.
Usage Considerations
Under normaL circumstances, a CP-6 user accessing a shared run unit need not be concerned about the program's shared status. Differences in behavior
appear onLy when a shared program is being debugged via the DELTA debugger (or some other, user-written debug tooL).
The major difference between debugging a shared program and debugging an unshared program concerns changes to the program's "procedure" memory pages.
These pages may be accessed by the program, but can never be modified by the DELTA command "UNSHARE" before setting instruction breakpoints or
modifying the program's procedure; the user must issue the command
"UNSHARE ALL" before setting data breakpoints.
• Some sophisticated programs make use of the M$ALIB monitor service to associate and pass commands to DELTA, to dispLay data or modify the
programs' procedure pages or perform other interesting tasks. If programs modify constant data or procedure, it is necessary for the programs to to issue an M$UNSHARE request before issuing the initial M$ALIB, to remove themselves from "shared" status and thus permit DELTA to modify their procedure.
CE62-00 Usage Considerations 10-3
Section 11 Specia' Shared Proce •• or.
A special shared processor is a run unit that may co-exist and interact with the user program. It differs from shared run-time libraries in that it resides in a working space other than that of the user; it is not LINKed with the user program.
The CP-6 system recognizes three types of special shared processors:
• Alternate Shared Libraries
• Debuggers
• Command processors.
Only one processor of a given type may be associated with a user at any time.
The standard CP-6 system includes I-D-S/II as the supplied alternate shared library, DELTA as the debugger, and IBEX as the command processor.
Installations may provide additional special shared processors for their own use in any of the three categories.
All special shared processors of a given type reside in a dedicated working space quarter concurrently with one another. Working space 6 is dedicated to Alternate Shared Libraries, working space 5 is dedicated to debuggers, and working space 4 is dedicated to command processors. The page table for a special shared processor is also contained within its working space.
A special shared processor run unit must consist of only pure procedure; there can be no DCBs or static data. Special shared processors may use the MSGETDCB monitor service to acquire DCBs in the user's Read-only Segment and use
dynamic data segments for all non-constant data. A data segment area is provided in each user's own working space for each type special shared
processor. One type of special shared processor does not have access to the data segments of another special shared processor, nor does the user have access to the data segments of any of the special shared processors. Refer to the map of user virtual memory in the Monitor Services Reference Manual,
Appendix E.
It is, then, the procedure portion of a special shared processor that resides in its own working space. The procedure portion is shared by all users
associated with the processor.
Entry to a special shared processor causes a change of domain, thereby
changing the areas of memory to which the processor has access. The areas of user memory to which the processor has access are determined by its type and are described in the discussion of each type of special shared processors.
CE62-QQ Special Shared Processors 11-1