Скачать BigTurbo - Add Extra 64K Code Segment for TP Program

Скачать файл (9,68 Кб)

* BigTurbo - (c) 1985 Kim Kokkonen, TurboPower Software.       *
*    written 9/85. (408)-378-3672. Compuserve 72457,2131.      *
*   This version is a prototype for a commercial product.      *
*  It is hereby released to the public domain for personal,    *
*                 non-commercial use only.                     *
*             We will appreciate any feedback.                 *

The BigTurbo system provides control to set up an extra 64K code segment for Turbo Pascal programs. It provides an alternative to overlays and chaining with some advantages over either technique.

The extra 64K code segment is written and compiled as a separate program from the main code segment. The main block of the separate segment is never used, unless you want to execute the program independently for debug purposes. BigTurbo allows you to call the global procedures in the extra code segment directly from the main program, or from procedures in the main program. It also allows procedures in the extra code segment to call each other and to call global procedures in the main code segment. The two code segments share a common data segment, heap and stack, and communication between the two segments is via global variables (parameters are not allowed at present).

BigTurbo requires files MAIN1.INC and MAIN2.INC to be included and compiled with the main program, and the files FAR1.INC and FAR2.INC to be included and compiled with the code comprising the extra code segment. As described below, the programmer must make minor modifications to the include files MAIN2.INC and FAR2.INC to make them work in his/her program.

The main program must have heap space reserved for the extra code segment when it is compiled to a .COM file (the extra code segment is loaded onto the heap of the main program). The extra code must be compiled to a .COM file prior to executing the main program. The code space, data space and heap/stack space options for the extra code segment are never accessed and are therefore arbitrary.

Hereafter, we will call the extra code segment the "Far" code segment.

Communication between the Main code segment and the Far code segment occurs only via global variables, similar to how Chain files are used. As a result the Far program should contain a set of global data definitions identical to those of the Main code segment. This is best managed by putting the global definitions in an include file, and including that file in both the Main and Far programs.

Improvements of BigTurbo over using Chain files or Overlays are as follows:

  • The Far code segment is loaded into memory only once, and remains there until the program completes. You get a full extra 64K segment (less runtime library overhead, about 10K) to use.
  • Any global procedure in the Far code segment may be called directly either from the main code segment or from within the Far code segment.
  • Any global procedure in the Main code segment may be called directly either from the Far code segment or from within the main code segment (as usual).
  • Upon completion of a call to the Far code segment, control returns to the calling procedure. Calls in the other direction work the same way.
  • The Main and Far code share the same heap and data segment, which provides adequate means of communication between the two.
  • The restrictions on what can call what are fewer than for overlays.
  • You can do the equivalent of overlays by DISPOSing of the code on the heap and loading another file's worth of code there. Only one extra code segment is allowed at a time, although the techniques here can clearly be extended to more segments with some logistic headaches.
  • These techniques are not specific to any particular version of Turbo, although we have assumed version 3.X (of any flavor).

Limitations of BigTurbo are as follows:

  • For now, calls across the code segment boundary may not use parameters, and must be made only to procedures (not functions).
  • The programmer must do a small amount of manual management to keep the required addressing tables set up (see SetupJumpTable below).
  • An extra copy of the Turbo runtime library is loaded into memory for the Far code segment. This costs about 10K bytes of RAM.
  • The Far code may not use global variables that are not used in the Main code segment, and vice versa. The order of the global variable definitions must be identical in each to guarantee proper addressing, just as with chain files.
  • The Far code should not use EXTERNAL procedures or INLINE code that enters and exits the global procedures in any way but the Turbo Pascal standard.
  • Stack checking is not currently implemented for Far calls. Such checking once implemented will be compiler version specific.
  • Far calls are somewhat slower than near calls (see the code in FarCallHandler and MainCallHandler to judge the overhead).
  • As with Turbo overlays, runtime errors will provide misleading addresses when they occur in the Far segment.
  • This hasn't been tested with overlays used being simultaneously, and we have a feeling it wouldn't work well.

Other Comments:

  • The procedures in the Far code segment may contain subprocedures, local variables, and typed constants just as usual. Calls to the subprocedures may use parameters as usual. A Far procedure may call itself recursively if desired.
  • The main executable block of the Far program may be empty. It will never be accessed, unless you are using it to debug the Far procedures independently.
  • The Far code is loaded into a location on the heap of the Main program. You need to reserve this amount of memory when you compile the Main program.
  • Your program should use the {$V-} directive to avoid problems in string length type checking with these routines.
  • MAIN1.INC and MAIN2.INC add about 1800 bytes of code to the main segment. FAR1.INC and FAR2.INC add about 700 bytes of code to the far segment.