home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / LANGUAGS / PASCAL-P / PP319DOC.LBR / SEGMENTS.MZN / SEGMENTS.MAN
Text File  |  2000-06-30  |  12KB  |  229 lines
  1. .macro chttl = Program#Segmentation
  2. .ch .chttl
  3. .hl 1 Overview
  4. Program segmentation is completely independant of program structure,  and
  5. is  controlled solely by the placement of (*$s'segname'*) compiler commands.
  6. Any procedure, whether nested or global, can be placed in any segment.  All
  7. segmentation may be performed after a program is operational.
  8. The source text never need be distorted to allow segmentation.
  9.  
  10. Under  CPM  and  the interpreter system no final decision  on  segmented
  11. operation need be taken until after compilation.   The output of the  compiler
  12. is  a  TIC  (temporary intermediate code) file which  contains  ".SEG"  pseudo
  13. codes, created from the s'segname' commands.
  14.  
  15. If this is converted into executable code with ASSMPCD no segmentation
  16. will be present in the final file.  This is often useful for debugging.  The
  17. output from ASSMPCD, however, will be in relocatable form, and must be passed
  18. through LINKER to create an executable file .bb (This may be prevented by
  19. use of [parm=64] when running ASSMPCD). .eb  Whenever a ".SEG" pseudo-op is
  20. encountered ASSMPCD assumes that a segmented file is being generated, and
  21. creates such a linkable object file.
  22.  
  23. Programs created from separately compiled modules will normally be segmented
  24. and use the techniques described in this chapter.  The modules may themselves
  25. be segmented.  See the chapter on Separate Compilation.
  26.  
  27. .hl 1 PCD segmentation (for interpreter execution)
  28. At  present,  to  implement  segmentation the "TIC" file  is  split  into
  29. multiple  single segment files with the utility  program  SPLITTIC.   Splittic
  30. will  create  a  file  for each named segment in  the  input  code,  with  the
  31. extension  _.TIC, and using the segment name truncated to .bb 8 characters
  32. (or to 7 characters with  a user  specified  prefix character). .eb
  33. Each of these segment files must  now  be
  34. converted  to a RBM (relocatable binary module) with ASSMPCD, just as a single
  35. segment program.  The results are then combined into a single program file by
  36. LINKER.   The first file linked must be .bb either "SEGS15.RBM" or
  37. "SEGS31.RBM",  which contains the outline of a segment table for a 15
  38. or 31 segment codefile.
  39.  
  40. .hl 2 Splitting the TIC file
  41. Execute:
  42. .i 10 B>runpcd splittic (ticfilename) .cr
  43. .bb or .cr
  44. .i 10 B>splittic (ticfilename) .b
  45. and select a suitable prefix character when requested (a CTL-Z reply, or
  46. redirecting input from nul with "_<nul" will omit the prefix). .eb
  47. The split files will occupy at least as much space as the original.
  48. At completion the
  49. original TIC file may be discarded.  The following assumes the selection
  50. of a prefix letter "X" (must be upper case) and that segments are named
  51. "segfile".  SPLITTIC reports on the actual filenames created during execution.
  52.  
  53. .hl 2 Assembly
  54. For each output file generated execute (omit "runpcd#" if using the _.COM
  55. versions) :
  56.  
  57. .i 10 B>runpcd assmpcd (xsegfile.tic,xsegfile.rbm)
  58.  
  59. .hl 2 Linking
  60. Execute linker as follows:
  61.  
  62. .i 10 B>runpcd linker (objfile.pcd, loadmap) .b
  63. replacing objfile and loadmap with appropriate file names.  Loadmap may be
  64. designated con, lst, or a diskfile.  The information on it will be used in
  65. the next step, and therefore it should normally not be routed to the console.
  66.  
  67. Reply to the first "filename" prompt with .bb "SEGS15.RBM", .eb
  68. and to the following
  69. prompts with the names of the just assembled segments.  Terminate the entries
  70. with an empty line.  The object file prompt is a last chance to change your
  71. mind on the output file name.
  72. The reply to the "loadpoint" prompt should be "0", and
  73. carriage returns can be entered for all other prompts.  LINKER will scan the
  74. files, announce that _.CODSIZE, _.DATASIZ, _.SEGS.,
  75. _.WHERE01 through _.WHERE15 are undefined, and
  76. ask whether more modules are available.  Reply "n".  LINKER will now generate
  77. the output file and the loadmap.  All intersegment procedure linkages have now
  78. been resolved.
  79. .note NOTE
  80. For programs using more than 15 segments replace SEGS15.RBM with SEGS31.RBM.
  81. .res
  82. .hl 2 Installing the segment map
  83. The  user must patch into the final file the addresses of the segments  in
  84. the code file, which are the loadpoint addresses of the segments in the LINKER
  85. output  loadmap  divided by 128.   These are CPM record numbers in  the  code
  86. file, and are the various ".WHEREnn" undefined in the preceding step.
  87. The   addresses   are  installed  at  locations  (segment_num*8)   and
  88. (segment_num*8+1),  high byte first.  Program "DISKEDIT" can be used for this.
  89. The two byte value at locations 0 and 1 (most significant byte first) must  be
  90. set  to  the negative count of segments present.   This is the undefined
  91. ".SEGS" in the previous step. At present no more than  31
  92. segments  can  be used, and this section generally assumes a maximum of 15.
  93. If errors are made in calculating these values the program will not load.
  94. Any further operations may be performed by the "TUNE" utility program.
  95.  
  96. .hl 2 Initial memory allocation
  97. The value at locations 4 and  5  of  the
  98. codefile  must be patched to specify the total codespace allocated.   This is
  99. the undefined ".CODSIZE" from the linking step. (.DATASIZ is unused). The  run
  100. time  system  will  then automatically swap code segments in and out  of  main
  101. memory  on demand,  and select segments for discard based on a least  recently
  102. used  algorithm.
  103. No more than the specified code space will be used for the program code.
  104. A  system  that buffers disk tracks  will  greatly  enhance
  105. performance.
  106.  
  107. The critical quantity to be selected is the codespace above.   If this is
  108. too small the system will thrash, while if too large sufficient execution time
  109. data space will not be available.  It must be at least as large as the largest
  110. single segment in the codefile,  or the program can never be loaded.  Normally
  111. this  space is selected sufficiently large to hold the main execution portions
  112. of  the program without any initialization or rarely used error handling
  113. segments.   This  will automatically swap such segments out of main  memory,
  114. and have negligible performance effects.
  115.  
  116. The  user  can also control the time span used by the  memory  management
  117. system  by altering byte 2 of the code file (range 2 to 255).   This  measures
  118. time in terms of inter-segment transfers performed.
  119. .note NOTE
  120. Since PCD files are quite compact, only the rare program will require
  121. segmentation.  Very large program systems can be written as a collection of
  122. procedures, pass data through a global area, and be supervised and
  123. co-ordinated by a small outer block using this segmentation scheme.
  124. There will be no necessity for duplicated code within sections of such
  125. a system if suitably segmented.
  126. .res
  127. .hl 1 Prestored alternative settings
  128. By convention, alternative settings for the  memory management period and
  129. codespace values are stored in locations  (8*i+5) and (8*i+6) to (8*i+7) for i
  130. := 1 to number_of_segments.   If these values are present the utility  program
  131. "TUNE"  can  be  quickly  used to  alter  the  memory-requirements/performance
  132. balance  of  the program.   TUNE may also be used to initially  install  these
  133. values.
  134.  
  135. The appearance of such a segment map may be examined by:
  136.  
  137. .b .i 10            A>diskedit pascalp.pcd
  138. .b followed by the command
  139. .b .i 10            r0
  140.  
  141. terminate the program by "q".  Use a copy of Pascalp in case of error.
  142. .note NOTE
  143. Other  areas within the segment map are used  by  the  memory
  144. manager. Therefore at run-time the map contents will be different.
  145. .b  Numerical
  146. input  to diskedit is normally decimal,  but may be prefixed by "_#" for
  147. hexadecimal input.  In some cases characters enclosed by single quotes may
  148. also be used.
  149. Diskedit provides no input line editing, and was built as a crude tool.
  150. .res
  151. After segment addresses and segment count have been entered via diskedit,
  152. further alterations may be performed by:
  153. .b .i 10            A>RUNPCD tune (codefilename.ext)
  154.  
  155. using  the unprompted "I" and "D" commands (?  gets a prompt).  This  is  much
  156. safer than diskedit.
  157.  
  158.  
  159.  
  160. .hl 1 The structure of a code file/segment
  161. All  executable  PCD files begin with a single descriptive integer,  which  is
  162. stored high byte first, in 2's complement notation.
  163.  
  164. If this integer is positive the PCD file consists of a single segment, and the
  165. integer is the length of that segment.   The segment proper is enclosed by the
  166. integer,  an unused word, and (at the end) a single byte describing the number
  167. of transfer vectors.   These five (total) bytes are not included in the length
  168. descriptor.
  169.  
  170. .hl 2 The segment map.
  171. If  this integer is negative it must be in the range -1 to -127 (only -31  for
  172. now),  and describes the number of segments in the PCD file.  The following is
  173. based  on  a 15 segment limitation.   The initial 128 bytes of the file are  a
  174. segment map, consisting of 16 8-byte entries which can be described as:
  175. .b .tp 11
  176. .asis
  177.    ARRAY[0..15] OF RECORD
  178.      CASE n OF
  179. 0: (   segcount     : -1..-15); (* hi byte first integer *)
  180.        tunevalue    : byte;
  181.        entryseg     : byte; (* id of outer block *)
  182.        codespace    : hifirstinteger;
  183.        dataspace    : hifirstinteger; (* not used yet *) );
  184. 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15:
  185.    (   fileaddress  : hifirstinteger; (* sector in PCD file *)
  186.        initflags    : byte;
  187.        workarea     : ARRAY[1..5] OF byte;)
  188. !
  189.  
  190. By convention bytes 3,  4, 5 of workarea are used to store optional values for
  191. tunevalue  and codespace.   Eventually initflags will be able to describe
  192. segments not to be swapped out and machine language segments.
  193. In operation this byte also holds segment usage history.
  194.  
  195. The  remainder of the PCD file holds segments organized as the single  segment
  196. PCD  file above,  but always filling complete sectors.   Thus the  fileaddress
  197. value can address 128 * 65536 bytes of code.   This is an absolute  limitation
  198. on  the  total size of a code file.   Similarly no segment can reference  more
  199. than 127 procedures (sum of internal and external),  and no segment can exceed
  200. 32K.
  201.  
  202. Data  segments are entirely separate,  and are addressed via  base
  203. registers.   The heap and stack areas must be contiguous,  but can range up to
  204. 64K total size.
  205.  
  206. .hl 2 The transfer vector.
  207. The last byte of each segment (located by the segment length descriptor)
  208. holds a count of transfer points.  0 means that only the main program entry
  209. is present.  This final byte is preceded by n (where n is the contents of
  210. the count byte + 1) HIBYTEFIRST 16 bit transfer vectors.  They may be of
  211. two types (and a code listing will show the type - See appendix C):
  212.  
  213. .hl 3 PCD transfers.
  214. These vectors are used by the CUP (call user procedure) (and its variants,
  215. CLP and CGP call local and call global) P-codes.
  216. If the value is negative, it is a self-relative pointer to the code within
  217. the segment.  If the value is positive, it contains two one byte fields,
  218. holding the segment number and entry number within the external segment.
  219.  
  220. .hl 3 Intrinsic transfers.
  221. These vectors are used solely by the CIP (call intrinsic procedure) P-code.
  222. It contains the absolute machine address of an external procedure.  Note
  223. that the external procedure is called with NO stack marker, but with the
  224. appropriate parameters (and possible function return value space) allocated
  225. on the stack.  The intrinsic is responsible for clean-up.
  226.  
  227. The zeroth transfer is only used for entry to the main program.  In other
  228. segments it will normally point to a CSP STP (halt) instruction.
  229.     [