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 / SIMTEL / CPMUG / CPMUG050.ARK / PPC.DOC < prev    next >
Text File  |  1984-04-29  |  10KB  |  223 lines

  1.  
  2.             PPC Users Manual
  3.  
  4.  
  5. How to use the compiler
  6. =======================
  7.  
  8. If you have a file named dog.pas and you want to compile it, you'd
  9. just type
  10.  
  11.     submit pc dog
  12.  
  13. The compiler will ask "LISTING?".  You reply with a single character;
  14. carriage return means no listing, any other character means yes listing.
  15. The listing will be sent to the console as the compilation proceeds.
  16. Any errors detected in the compilation are flagged in this listing.
  17. At some point (hopefully reasonably near to the point of infraction)
  18. the error number will be inserted into the listing, enclosed in ">>"
  19. and "<<".  The line following an error will start with "********"
  20. and otherwise be blank to call attention to the error.  The compiler
  21. will also wait for a single character from the console before
  22. compilation continues.  This is so people with crt's can see the
  23. error.  Error numbers should be looked up in Jensen and Wirth (see
  24. below).  Error number 99 is pound sign ("#") expected.
  25.  
  26. The compiler should work with a 32k CP/M and might work in 24k, but
  27. there are no memory overflow checks.  If it hangs or something, you
  28. probably don't have enough memory.
  29.  
  30. On good sized programs, the compiler manages to get about 300-400
  31. lines of Pascal translated to object per minute.  These figures were
  32. taken on my system with 2mHz Z-80, 8" disk, running under SPEED.
  33. Compilation speed will fall to less than half this rate without SPEED,
  34. thus SPEED is strongly recommended.  This is particularly true if
  35. you use the submit file to do the compilation.  The run time package
  36. does only single sector disk buffering and this too makes SPEED
  37. very important.
  38.  
  39.  
  40.  
  41. How it all works
  42. ================
  43. The program PPC.COM takes your Pascal source and makes a single pass
  44. over it translating it to a sort of p-code as it goes.  This p-code is
  45. written to disk.  PFET.COM reads the p-code file on its first pass,
  46. assigning 8080 addresses to all p-code labels and storing the p-code
  47. in memory for the second pass.  On its second pass, PFET reads the
  48. p-code from memory and generates the actual 8080 object code.  This
  49. code is written to a disk file.  The last step in compilation is to
  50. link the generated object code to the run time package.  This is done
  51. by simply using PIP to concatenate the run time package and the object
  52. file from PFET to produce an executable .COM file.  The compiler (PPC)
  53. is written in Pascal, as is the p-code translator (PFET).  The run time
  54. package is written in assembler.
  55.  
  56.  
  57.  
  58. Differences from "standard" Pascal
  59. ==================================
  60.  
  61. This section will detail the ways in which ppc deviates from standard
  62. Pascal as defined in "Pascal User Manual and Report", second ed., K.
  63. Jensen and N. Wirth.
  64.  
  65.  
  66. Two additional reserved words have been defined:  get and put.
  67. The following words are not now considered reserved, but are
  68. in standard Pascal, so they should be avoided:  file, goto, in, label,
  69. nil, packed, set, and with.
  70.  
  71. The ASCII tab character is an acceptable white space character.
  72.  
  73. Comments are begun with the sequence "(*" and ended with "*)".
  74.  
  75. Identifiers may be very long, but only the first 8 are significant.
  76.  
  77.  
  78. The data type Boolean is not supported.  Relational and logical
  79. operators may be used only in if statements.  The boolean constant
  80. identifiers true and false are not defined.  The not operator is
  81. not implemented.  These are the legal relational and logical
  82. operators:  =, <>, <, <=, >=, >, and, and or.
  83.  
  84. The data type integer is available.  Values must be in the range -32768 to
  85. 32767.  There are no standard functions such as abs, sqr, trunc, etc.
  86. The constant maxint is not defined by the compiler.  The type integer is
  87. identical to type word.  The following operations are defined on integers:
  88.  
  89.     *    multiply
  90.     /    divide and truncate (why use div? int's are all you've got!)
  91.     +    add
  92.     -    subtract
  93.  
  94. Multiplication and division are presently implemented with repeated
  95. addition and subtraction (gag!).  This makes the order of the operands
  96. critical.  If one operand is likely to be less than the other, put the
  97. lesser operand on the left of the multiplication symbol for best speed.
  98. Dividing a large number by one takes a long time -- dividing it by zero
  99. takes forever!  (It's not that I'm not aware of the shiftng methods
  100. of division and multiplication, it's just that I wanted something quick
  101. and didn't feel like looking up the good routines.  I've never felt
  102. the need to replace these routines with the good ones.)
  103.  
  104. Also note that there is no integer negation.  If you want negative one,
  105. write it as 0-1.
  106.  
  107. The type real is not supported.
  108.  
  109. The type char is not supported, but see type alfa below.
  110.  
  111. The type alfa can hold eight characterers.  Alfas can be assigned and
  112. compared just like integers (just don't try to do math on them!).
  113. All relational operators are defined using the ASCII collating sequence.
  114. Length can't enter into the compariosn because alfas are always eight
  115. characters long (it's up to you to supply padding).  Alfas may be passed
  116. as parameters.
  117.  
  118.  
  119. Since files are not supported, the program heading is not needed, and
  120. in fact, is not allowed.  The first thing the compiler expects to see
  121. are the global constant declarations.
  122.  
  123. Goto statements are not supported, therefore label declarations are not
  124. needed and not permitted.
  125.  
  126. Constant declarations are pretty much the same as in regular Pascal,
  127. except that leading signs are not allowed and character constants
  128. can be only one character in length.  A minor extension is that I put
  129. in limited compile time constant expressions to make coding the
  130. translator easier.  See the syntax graphs to see where these can be
  131. used.
  132.  
  133. Variable declarations have the restriction that the type must be
  134. a type identifier and may not be a complex type.  Thus
  135.  
  136.     var months : array [ 1 .. 12 ] of integer;
  137.  
  138. is illegal, while
  139.  
  140.     type mtharray = array [ 1 .. 12 ] of integer;
  141.     var  months : mtharray;
  142.  
  143. is legal.
  144.  
  145. In this implementation, functions can return only integer values.
  146. This makes it unnecessary (and illegal) to give a function return type
  147. in the function declaration.
  148.  
  149.  
  150. The case statement is limited in that it cannot accept multiple case
  151. labels on the same statement.  On the other hand, it has been extended
  152. to allow an else statement which is executed when none of the case
  153. labels match the expression value.  See the syntax graphs for the syntax.
  154.  
  155.  
  156. Single dimensional arrays of integers and alfas (the two "built-in" types)
  157. are allowed.  You can also declare arrays of subrange or enumerated types,
  158. but these are treated as arrays of integers and take the same amount of
  159. storage.  Of course, arrays of arrays are not allowed, as that would
  160. be more than one dimension.
  161.  
  162. If a simple alfa variable appears with a subscript after it, it is
  163. treated as though it were an array of integers.  This fact can be used
  164. to get at the individual characters of an alfa variable.  For example,
  165. if "a" is a simple (not an array) alfa variable, then a[0] refers to
  166. the first two characters.  The least significant eight bits would
  167. contain the first character and the most significant eight bits would
  168. contain the second character.
  169.  
  170.  
  171. Record types are not allowed.  Therefore, there is no need for a with
  172. statement.
  173.  
  174.  
  175. There is no set type.  (However, it shouldn't be too hard to implement
  176. a 64-bit set type using the p-instructions already around for alfa
  177. variables . . . ).
  178.  
  179.  
  180. There are no pointer types, and consequently, no new function.
  181.  
  182.  
  183. There are no files and no read or write statements.  All input and
  184. output is done with the put and get statements.  These are only vaguely
  185. similar to the standard Pascal put and get.  GET#0 gets one character
  186. from the input file.  PUT#0 sends its output to the output file.  PUT#1
  187. sends its output unconditionally to the console.  The arguments to the
  188. put statements consist of a series of expressions separated by commas.
  189. If an expression evaluates to an alfa, all eight characters of the alfa
  190. are printed.  Integer expressions followed by a pound sign ('#') will
  191. print the decimal value of the expression.  If no pound sign follows
  192. the expression, the low eight bits of the expression are sent as one
  193. character.  The input and output files mentioned above can be either
  194. disk files or console input and output.  Which is used depends on what
  195. is typed on the command line following the compiled .com file when it
  196. is executed.  If the first filename following the .com file name is
  197. blank or '*', then input characters are taken from the console.  If
  198. it is the name of a disk file, then input comes from that disk file.
  199. A similar rule applies to the second filename following the command
  200. and the destiny of the output characters.
  201.  
  202.  
  203. Var parameters are different in that if one parameter to a procedure
  204. is to be var, then all parameters must be var parameters.  This is
  205. a silly restriction that should be easily removed by any talented
  206. compiler hacker.  There is a also a small kludge to make the compiler's
  207. job easier;  the word var must appear in the call to all procedures
  208. with var parameters, as well as in the declaration.  This is very
  209. easy to forget an a real nuisance at times.  Somebody please fix.
  210.  
  211.  
  212. It is possible to forward declare procedures an functions, but as
  213. with var parameters, there is a minor syntactic kludge to make the
  214. compiler's life easier.  The forward part is handled in the normal
  215. way except that you D-O-N-'-T give the parameter list (the compiler
  216. never checks procedure calls against their declarations anyway!).
  217. When you actually want to declare the procedure, use the form
  218.  
  219.     procedure foo(<real parameter list>); backward;
  220.  
  221. This gives the compiler a hint it can't miss that this procedure
  222. was forward declared earlier!
  223.