home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / sigm / vol114 / future.dev < prev    next >
Encoding:
Text File  |  1984-04-29  |  4.1 KB  |  135 lines
  1. Some thoughts about future development of PISTOL:
  2. (March 10, 1982)
  3.  
  4.     It is expected that several major extensions to
  5. PISTOL can and will be possible for some installations.
  6.  
  7.     Extended PISTOL versions will be denoted by certain
  8. letter conventions (which follow the version number).  For
  9. example, *** PISTOL 2.0A *** would be used for a version
  10. possessing assembly capabilities.  If several extensions
  11. coexist, necessitating several letter suffixes, they should
  12. appear in alphabetical order (e.g. PISTOL 2.0ADF).  Wherever
  13. possible associated files should be renamed (e.g. PBASE2 -->
  14. PBASE2A).
  15.  
  16.     Here is a list of likely extesions:
  17.  
  18.     'A')    Assembly language capability; obviously this
  19. is a machine dependent extension.  STOIC is a good example
  20. and model of an 8080 macro assembler.
  21.  
  22.     'D')    Long or Double precision signed integer
  23. number and arithmetic capability.  To help provide typing
  24. protection and simplify programming, there should be a new,
  25. separate stack for these long or double precision numbers.
  26. Also, there should be a separate area of RAM set aside for
  27. storage of these types of numbers.  If memory protection is
  28. supported, then the operations with these types of numbers
  29. should check memory references to lie within that separate
  30. region; this is analogous to the W@ and C@ (as well as W!
  31. and C! protection).  No assumptions should be made as to the
  32. ordering of significance and/or the location of the sign
  33. bit.  Some relevent additional definitions would be:
  34.  
  35. D+    adds two long integer numbers and leaves the long
  36.     result on the D-stack.
  37.  
  38. D-    like D+, but for subtraction.
  39.  
  40. D*    like D+, but for multiplication.
  41.  
  42. D/    like D+, but for division.
  43.  
  44. DMOD    like D+, but for MOD .
  45.  
  46. D/MOD    like D+, but for /MOD [two answers].
  47.  
  48. D.. ,
  49. DLT ,    etc: analogous to integer comparisons.
  50.  
  51. DW    used like W, but provides size of long integer.
  52.  
  53. DW@    analogous to W@ .
  54.  
  55. DW!    analogous to W! .
  56.  
  57. DS@    analogous to S@ .
  58.  
  59. D=    analogous to = ; current RADIX used as for = .
  60.  
  61. D->I    Convert long integer into ordinary integer (single
  62.     precision).  If out of range an error message and
  63.     ABORT should occur. Transfer occurs from D-stack to
  64.     regular stack.
  65.  
  66. I->D    Convert ordinary integer to long integer.  Transfer
  67.     occurs from regular to D-stack.
  68.  
  69.  
  70.  
  71.     'F')    Floating point arithmetic capability should
  72. be in complete analogy to the 'D' option above.  To help
  73. provide typing protection and simplify programming, there
  74. should be a new, separate stack for these floating point
  75. numbers. Also, there should be a separate area of RAM set
  76. aside for storage of these types of numbers.  If memory
  77. protection is supported, then the operations with these
  78. types of numbers should check memory references to lie
  79. within that separate region; this is analogous to the W@ and
  80. C@ (as well as W! and C! protection).
  81.  
  82. F+    F-    F*    F/    F..    FLT ,etc.
  83. FW    FW@    FW!    FS@    F/W    F=
  84. E= [exponential form]    F->I    I->F
  85.  
  86. The i/o conversions are always in base ten (decimal).
  87.  
  88.  
  89.  
  90.     'DF')    (Both 'D' and 'F' options).  We should
  91. provide in addition:
  92.  
  93. F->D    float to long (error message and ABORT on overflow).
  94.     Transfer occurs from F-stack to D-stack.
  95.  
  96. D->F    long integer to float.  Transfer occurs from D-stack
  97.     to F-stack.
  98.  
  99.  
  100.  
  101.     'P')    Port access capability by the use of:
  102.  
  103. P@    fetches current value from port number on TOS.
  104.  
  105. P!    sends NTT to TOS's port.
  106.  
  107.     Details are implementation and hardware dependent;
  108. as with everything else, it should be detailed in HELP
  109. documentation.
  110.  
  111.  
  112.  
  113.     'V')    Visual editor functional capability;
  114. (Cursor control and direct, full-duplex character i/o):
  115.  
  116. VINIT    does whatever is necessary to enable direct i/o
  117.     functions to take place.
  118.  
  119. VIN    returns immediately with a character typed from the
  120.     console or a 0 to indicate no character available
  121.     yet.  There should NOT be an automatic echo within
  122.     VIN.  There should be no interception of any control
  123.     codes by the operating system (such as contol-C will
  124.     not abort PISTOL).
  125.  
  126. VOUT    outputs a character to the CRT WITHOUT any
  127.     modification (such as appending <LF> after <CR>).
  128.     It would be most unfortunate if cursor addressing
  129.     data were in any way modified.
  130.  
  131. VEND    does whatever is necessary to terminate direct i/o
  132.     functions and revert console i/o to line-buffered
  133.     mode.
  134.  
  135.