home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PASCAL / MADTRB33.ZIP / BIGTUR.DOC next >
Encoding:
Text File  |  1986-02-10  |  6.8 KB  |  145 lines
  1.  
  2.  ********************************************************************
  3.  * BigTurbo - copyright (c) 1985 Kim Kokkonen, TurboPower Software. *
  4.  ********************************************************************
  5.  *      written 9/85. (408)-378-3672. Compuserve 72457,2131.        *
  6.  *     This version is a prototype for a commercial product.        *
  7.  *    It is hereby released to the public domain for personal,      *
  8.  *                   non-commercial use only.                       *
  9.  *               We will appreciate any feedback.                   *
  10.  ********************************************************************
  11.  
  12.  The BigTurbo system provides control to set up an extra 64K code
  13.  segment for Turbo Pascal programs. It provides an alternative to
  14.  overlays and chaining with some advantages over either technique.
  15.  
  16.  The extra 64K code segment is written and compiled as a separate program
  17.  from the main code segment. The main block of the separate segment is
  18.  never used, unless you want to execute the program independently for
  19.  debug purposes. BigTurbo allows you to call the global procedures in the
  20.  extra code segment directly from the main program, or from procedures
  21.  in the main program. It also allows procedures in the extra code segment
  22.  to call each other and to call global procedures in the main code segment.
  23.  The two code segments share a common data segment, heap and stack, and
  24.  communication between the two segments is via global variables
  25.  (parameters are not allowed at present).
  26.  
  27.  BigTurbo requires files MAIN1.INC and MAIN2.INC to be included and
  28.  compiled with the main program, and the files FAR1.INC and FAR2.INC to
  29.  be included and compiled with the code comprising the extra code segment.
  30.  As described below, the programmer must make minor modifications to
  31.  the include files MAIN2.INC and FAR2.INC to make them work in his/her
  32.  program.
  33.  
  34.  The main program must have heap space reserved for the extra code
  35.  segment when it is compiled to a .COM file (the extra code segment
  36.  is loaded onto the heap of the main program). The extra code must be
  37.  compiled to a .COM file prior to executing the main program. The
  38.  code space, data space and heap/stack space options for the extra
  39.  code segment are never accessed and are therefore arbitrary.
  40.  
  41.  Hereafter, we will call the extra code segment the "Far" code segment.
  42.  
  43.  Communication between the Main code segment and the Far code segment
  44.  occurs only via global variables, similar to how Chain files are used.
  45.  As a result the Far program should contain a set of global data definitions
  46.  identical to those of the Main code segment. This is best managed by
  47.  putting the global definitions in an include file, and including that
  48.  file in both the Main and Far programs.
  49.  
  50.  Improvements of BigTurbo over using Chain files or Overlays are as follows:
  51.  
  52.   1) The Far code segment is loaded into memory only once, and remains
  53.      there until the program completes. You get a full extra 64K segment
  54.      (less runtime library overhead, about 10K) to use.
  55.  
  56.   2) Any global procedure in the Far code segment may be called directly
  57.      either from the main code segment or from within the Far code
  58.      segment.
  59.  
  60.   3) Any global procedure in the Main code segment may be called directly
  61.      either from the Far code segment or from within the main code
  62.      segment (as usual).
  63.  
  64.   4) Upon completion of a call to the Far code segment, control returns
  65.      to the calling procedure. Calls in the other direction work the
  66.      same way.
  67.  
  68.   5) The Main and Far code share the same heap and data segment, which
  69.      provides adequate means of communication between the two.
  70.  
  71.   6) The restrictions on what can call what are fewer than for overlays.
  72.  
  73.   7) You can do the equivalent of overlays by DISPOSing of the code
  74.      on the heap and loading another file's worth of code there. Only
  75.      one extra code segment is allowed at a time, although the techniques
  76.      here can clearly be extended to more segments with some logistic
  77.      headaches.
  78.  
  79.   8) These techniques are not specific to any particular version of
  80.      Turbo, although we have assumed version 3.X (of any flavor).
  81.  
  82.  
  83.  Limitations of BigTurbo are as follows:
  84.  
  85.   1) For now, calls across the code segment boundary may not use
  86.      parameters, and must be made only to procedures (not functions).
  87.  
  88.   2) The programmer must do a small amount of manual management to keep
  89.      the required addressing tables set up (see SetupJumpTable below).
  90.  
  91.   3) An extra copy of the Turbo runtime library is loaded into
  92.      memory for the Far code segment. This costs about 10K bytes of
  93.      RAM.
  94.  
  95.   4) The Far code may not use global variables that are not used in the
  96.      Main code segment, and vice versa. The order of the global variable
  97.      definitions must be identical in each to guarantee proper addressing,
  98.      just as with chain files.
  99.  
  100.   5) The Far code should not use EXTERNAL procedures or INLINE code that
  101.      enters and exits the global procedures in any way but the Turbo Pascal
  102.      standard.
  103.  
  104.   6) Stack checking is not currently implemented for Far calls. Such
  105.      checking once implemented will be compiler version specific.
  106.  
  107.   7) Far calls are somewhat slower than near calls (see the code in
  108.      FarCallHandler and MainCallHandler to judge the overhead).
  109.  
  110.   8) As with Turbo overlays, runtime errors will provide misleading
  111.      addresses when they occur in the Far segment.
  112.  
  113.   9) This hasn't been tested with overlays used being simultaneously, and
  114.      we have a feeling it wouldn't work well.
  115.  
  116.  Other Comments:
  117.  
  118.   1) The procedures in the Far code segment may contain subprocedures,
  119.      local variables, and typed constants just as usual. Calls to the
  120.      subprocedures may use parameters as usual. A Far procedure may
  121.      call itself recursively if desired.
  122.  
  123.   2) The main executable block of the Far program may be empty. It will
  124.      never be accessed, unless you are using it to debug the Far procedures
  125.      independently.
  126.  
  127.   3) The Far code is loaded into a location on the heap of the Main program.
  128.      You need to reserve this amount of memory when you compile the
  129.      Main program.
  130.  
  131.   4) Your program should use the {$V-} directive to avoid problems in
  132.      string length type checking with these routines.
  133.  
  134.   5) MAIN1.INC and MAIN2.INC add about 1800 bytes of code to the main
  135.      segment. FAR1.INC and FAR2.INC add about 700 bytes of code to
  136.      the far segment.
  137.  
  138.  *******************************************************
  139.  *              See the example files                  *
  140.  *                  MAINEXAM.PAS                       *
  141.  *                  FAREXAM.PAS                        *
  142.  *                    EXAM.GLO                         *
  143.  *   for proper usage of the following include files   *
  144.  *******************************************************
  145.