Previous: Characteristics of p-code segments
Up: A Quick Reference to p-System Structures
Next: Looking at Segments
Previous Page: Characteristics of p-code segments
Next Page: Looking at Segments

On p-System Code Structure

The p-machine instruction set used by the p-System is a stack-based instruction set, highly optimised for space and for the implementation of programs in Pascal-class languages. An average piece of p-code might be 1/3 to 1/2 the size of the source code that generated it, and therefore tends to be much more compact for space than equivalent native code.

Executable code on the p-System is kept in self-contained structures called segments (antedating, and unrelated to, the Intel memory addressing scheme). Each segment is loaded individually and entirely into memory, and accessed by external code through a built-in table that translates routine numbers into internal byte offsets.

The p-System file system is organised around the file block, which contains 512 bytes. Files of executable code segments therefore consist of a series of blocks. The first is a segment dictionary, listing up to 16 code segments by name, and containing for each entry several pieces of information, such as: the disc address where it is to be found; and the type of segment (whether main program, a unit segment, a segment routine, etc).

If the file contains a large number of segments, as a code library file might, further segment dictionaries may be located down the file to provide the full number of entries. The location of each is given by its predecessor: a linked list of dictionary blocks. This file structure is maintained both by the compiler and by the system's librarian and disassembly utilities; any code file can serve as a library, and in fact a callable code file is only distinguished by containing an actual program segment.

Each segment itself contains a list of the names of the other segments whose routines it calls, and the ID number within each of those other segments of each such procedure. When a segment gets loaded as part of the execution of a program, the operating system is prepared to search the segment's file, the operating system's own files, and a user-supplied list of other code files for the other segments that this segment names. The p-system is therefore almost completely dynamically linked (the exception doesn't concern us here), and a single copy of a given segment, somewhere in the system, is all that any client program needs.

When a segment is loaded, it goes into the operating system's code pool, where it will remain resident until its space is demanded by another segment of higher priority. (The actual replacement policies, and measures to avoid dropping any segments at all until truly necessary, are described in the architecture guide.) The termination of a running program does not, in itself, cause the release of its segments, or other segments it was using. This means that if a succession of programs uses the same segment, it is increasingly likely that that segment will remain resident and not require re-loading, throughout that succession.

The operating system itself is constructed of units, contained in the operating system file SYSTEM.PASCAL; some are accessible to user programs for system-level services. One is CommandIO, which permits user programs to effect program chaining by queueing successive programs for execution following their own termination (which the CommandIO call does not, itself, cause). When the current program ends, the command monitor checks this queue to see if there is a program named there to execute; and if there is, it omits resetting the screen or re-displaying the command menu promptline. Transfer of control between programs therefore appears seamless to the user. The p-System's Ports uses this method to chain all the program components of a dialogue together.