Previous: Creating a Monoprogram Dialog
with Turbo Pascal
Up: Creating a Monoprogram Dialog
with Turbo Pascal
Next: Converting Modules into Units
Previous Page: Creating a Monoprogram Dialog
with Turbo Pascal
Next Page: Converting Modules into Units

Rationale

Multiple-program format was established under the UCSD p-System, which has several features making such an organisation easy to implement:

• p-System programs occupy relatively little space on disc:
  • p-System: the p-machine instruction format is both very compact, and optimised for the implementation of higher-level languages.

    DOS: Average 808*6 instruction uses roughly 3 to 4 times the space of average p-machine instruction; and more instructions may be required for equivalent Pascal source because p-machine is designed for implementation of that source. This situation may improve somewhat, though, as code generation for Turbo Pascal improves, and starts to take advantage of additional 286 and 386 instructions.

  A single UCSD Pascal program code file therefore requires much less disc space than the equivalent in Turbo Pascal.

• DOS: the only packaging of code DOS handles is an entire .EXE or .COM file, which it loads completely if there is enough memory, or does not load at all if there is not. All the code the program uses must be contained in that file, unless the code itself has some special arrangement, within the scope of the program, for loading code from elsewhere. DOS has no arrangements for permitting code sharing across programs.

  p-System: packages code in self-contained, atomic collections of procedures, called segments (no relationship to the Intel memory addressing scheme). A segment provides all the information needed for other segments to call its routines or reference its data at runtime, instead of being linked once and forever into a single running program file. Among the results:

  • No segment need be duplicated in the system, as the operating system provides every program being loaded for execution with access to the one copy. A single copy of a library file is all that need be provided on disc, no matter how many programs will use it.

  • Runtime memory management keeps those segments resident the longest which are most needed. Need is determined by an ``activity count'' which tracks the number of calls that have been made to routines in the segment. Common library routines tend to be the most ``active'' and therefore to be kept in memory the longest. So as successive programs use those segments, they need to be re-read more and more seldom from the disc.

  • All dialogues so far produced have fit on a single floppy disc each. Therefore no p-System dialogue has yet needed the (probably) non-technical student to intervene to change a disc.

• the p-System exports routines that permit programs to supply the command-line handler the next program name to execute; and the command-line handler, finding this already supplied, prints no request to the screen, but immediately executes the named program. There is no need to risk attempting to circumvent the operating system's normal mechanism for executing programs.

In DOS, using Turbo Pascal, quite different considerations apply:

• code is large: not only is average instruction size roughly 3 times that of p-machine code, but each program must contain its own copies of the routines it uses from the run-time library.
• there is no memory control