doc.h 9.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226
  1. /* doc.h Copyright (C) 1991-4 Codemist Ltd */
  2. /* Signature: 440bda8c 08-Dec-1995 */
  3. Although this file is stored with suffix ".h" it is not intended to be
  4. compiled. It is just documentation about CSL and its history.
  5. -------------------------------------------------------------------------------
  6. April 95:
  7. Introduce vectors containing binary.
  8. mkvect8/mkvect16/mkvect32/fmkvect32/fmkvect64
  9. to hold 8, 16 and 32 bit (unboxed) integers and 32/64 bit (unboxed) floats.
  10. Access via putv8/getv8 putv16/getv16 putv32/getv32 fputv32/fgetv32
  11. fputv64/fgetv64. NOT integrated with other (generic) vectore handling
  12. functions.
  13. double-execute() and undouble-execute() are like trace() and untrace() but
  14. cause the nominated functions to double their costs. Only at first actually
  15. does anything for functions with fixed nuymbers of args.
  16. November 94:
  17. Introduction of "mixed" vectors.
  18. October/November 94:
  19. Adjustment of various source files to support Watcom C 10.0 as well as
  20. Zortech, GCC and Microsoft foir use on 80x86.
  21. May 30 1994:
  22. In COMMON Lisp mode the compiler now supports FLET, LABELS and PROGV.
  23. Interpreted PROGV mended.
  24. May 20 1994:
  25. Bug fixed in preserve.c that meant that on 16 bit machines compressing a heap
  26. image could loop if a suitable segment boundary in the file fell on a
  27. 64Kbyte boundary! Some attempt to make bytestream_interpret more compact
  28. by moving some fragments of it out of line.
  29. May 18 1994:
  30. PRESERVE now (really) has optional args. First specifies a restart function
  31. to be called, the second is a banner to display when the image is reloaded.
  32. Reduce now uses this mechanism to gets its banner displayed.
  33. Lexical closures supported in the bytecode compiler (for variable reference
  34. but not GO or RETURN-FROM) and 3 new opcodes (closure, loadlex, storelex)
  35. introduced in bytes1.c to support same.
  36. May 16 1994:
  37. By default the MSB of pointers is now determined at run time (rather than
  38. being a manifest value compiled into the code). Exception conditions
  39. changed to set the 1 bit of nil rather than the 0x80000000 bit. More
  40. macros used to test and set exception conditions.
  41. 286 version uses software ticks. Seems as if real asynchronous ticks
  42. are needed most on just those machines least liable to support them reliably.
  43. Output column control used to be muddled between stdout (eg trace) output
  44. and regfular user printing. Now improved.
  45. Better build procedures for patches and updated help files for REDUCE, and
  46. initial banner for Reduce displayed earlier.
  47. May 1 1994:
  48. Support for calls to functions with large numbers of arguments is
  49. improved. In particular in Common Lisp mode it is possible to have
  50. more than 50 args.
  51. Line-length overflow checking for printing of big numbers implemented.
  52. binary printing for numbers, and case fold up as well as down, supported.
  53. Demonstration version of Reduce brought back into step with rest of system.
  54. car and filesign utilities scan files in alphabetic order under DOS and NT.
  55. 'demo put in lispsytem!* list if help function available.
  56. build files for Reduce include help system and patches, and can build
  57. demonstration system correctly.
  58. -------------------------------------------------------------------------------
  59. DATA REPRESENTATION
  60. ===================
  61. All objects in CSL are represented by 32-bit words, and each object in
  62. memory is aligned at an 8-byte boundary. The bottom 3 bits of a word
  63. aare used as tags, and indicate how the rest of the word should be
  64. interpreted. In some cases the rest of the word is just direct information
  65. (eg small integers are handled this way) and then the 0x8-bit is used by
  66. the garbage collecter. In other cases the 32-bit word contains the address
  67. in memory of some object, and in that case its most significant bit is
  68. reserved for use by the garbage collector. Thus all valid addresses must have
  69. the same sign (but this can be either + or -). Many objects in memory have
  70. a header word at their start that indicates their length and gives more
  71. details about their type. The encoding of object lengths means that the
  72. largest possible single object in CSL would be 4 Mbytes long.
  73. The coding in the low bits of a word is as follows:
  74. x x x | x 0 0 0 cons cell (and NIL in Common Lisp mode)
  75. x x x | G 0 0 1 28-bit integer (G = garbage collector bit)
  76. x x x | G 0 1 0 characters, vec-hdrs, other oddities (immediate)
  77. x x x | G 0 1 1 28-bit short float if Common Lisp mode
  78. x x x | x 1 0 0 a symbol
  79. x x x | x 1 0 1 bignum. {rational number, complex number}
  80. x x x | x 1 1 0 Lisp vector (includes strings etc)
  81. x x x | x 1 1 1 pointer to boxed floating point number
  82. Pointers reserve the 0x80000000L bit for the garbage collector,
  83. assuming that all addresses are in the same half of the space. This
  84. of course is a slightly dodgy assumption that may be false on some
  85. computers.
  86. Header words in the vector heap
  87. If the bottom 3 bits of a word are 010 (TAG_ODDS) the word is
  88. treated as immediate data. In that case the 1000 bit (GC_BIT_I)
  89. is kept free for use as a mark bit. The next bits up classify the
  90. object:
  91. | x x 0 0 | * 0 1 0 valid immediate date in heap
  92. but can also be used as vector headers
  93. | x x 0 1 | * 0 1 0 symbol headers
  94. | x x 1 0 | * 0 1 0 number headers
  95. | x x 1 1 | * 0 1 0 vector headers
  96. Data that could be in the heap or on the stack decodes further:
  97. x x | 0 0 0 0 | * 0 1 0 character
  98. x x | 0 1 0 0 | * 0 1 0 handle/offset to BPS page
  99. x x | 1 0 0 0 | * 0 1 0 [handle/offset to literal vector]
  100. x x | 1 1 0 0 | * 0 1 0 special marker (SPID) left on stack
  101. to help interpreter
  102. The remaining 24 bits of the word are available for data. The BPS and
  103. literal vector handles in this case are for a segmented memory
  104. implementation, and the 24 bit address has its top 10 bits identifying
  105. a page number, then 14 bits giving a WORD offset into the associated
  106. page, which can thus be up to 64 Kbytes large. Or more depending on
  107. PAGE_BITS. Literal vectors done this way are not used at present.
  108. For Standard Lisp only 8 bits of character information is needed - the
  109. remaining bits are there to support font etc information in a Common
  110. Lisp world.
  111. . . . . | g f 0 1 | * 0 1 0 symbol header
  112. g global variable
  113. f fluid (special) variable
  114. The remaining bits in the word are used as follows
  115. 00000100 symbol names a special form
  116. 00000200 symbol has a definition as a macro
  117. 00000400 an unprinted gensym (so print-name is not complete yet)
  118. 00000800 has a definition in C from the C-coded kernel
  119. 00001000 just carries a code-pointer (codep test)
  120. 00002000 any gensym, printed or not
  121. 000fc000 fastget code in this is used as a p-list indicator
  122. 00100000 traced
  123. 00200000 is external in its home package
  124. ffc00000 reachability in first ten packages
  125. The remaining header words hold the length (in bytes) of the object
  126. (including the length of the header word) in the upper 22 bits of the
  127. word. This puts a limit of 4 Mbytes on the largest possible single
  128. object in this Lisp.
  129. 0 0 | 0 0 1 0 | * 0 1 0 bignum header word
  130. 0 0 | 0 1 1 0 | * 0 1 0 ratnum
  131. 0 0 | 1 0 1 0 | * 0 1 0 complex number
  132. 0 0 | 1 1 1 0 | * 0 1 0 NOT USED (non-float number)
  133. 0 1 | 0 0 1 0 | * 0 1 0 single float
  134. 0 1 | 0 1 1 0 | * 0 1 0 double float
  135. 0 1 | 1 0 1 0 | * 0 1 0 long float
  136. 0 1 | 1 1 1 0 | * 0 1 0 NOT USED (floating number)
  137. Note that headers for numbers are 0x|xx10|x010 and the 0x100 bit flags
  138. floating point cases
  139. n n | n 0 1 1 | * 0 1 0 bitvector with nnn bits in last byte
  140. 0 0 | 0 1 1 1 | * 0 1 0 string
  141. 0 0 | 1 0 1 1 | * 0 1 0 (bitvector)
  142. 0 0 | 1 1 1 1 | * 0 1 0 simple vector
  143. 0 1 | 0 0 1 1 | * 0 1 0 (bitvector)
  144. 0 1 | 0 1 1 1 | * 0 1 0 BPS
  145. 0 1 | 1 0 1 1 | * 0 1 0 (bitvector)
  146. 0 1 | 1 1 1 1 | * 0 1 0 hash table
  147. 1 0 | 0 0 1 1 | * 0 1 0 (bitvector)
  148. 1 0 | 0 1 1 1 | * 0 1 0 SPARE contains binary data
  149. 1 0 | 1 0 1 1 | * 0 1 0 (bitvector)
  150. 1 0 | 1 1 1 1 | * 0 1 0 Common Lisp array (header block)
  151. 1 1 | 0 0 1 1 | * 0 1 0 (bitvector)
  152. 1 1 | 0 1 1 1 | * 0 1 0 encapsulated stack pointer
  153. 1 1 | 1 0 1 1 | * 0 1 0 (bitvector)
  154. 1 1 | 1 1 1 1 | * 0 1 0 Common Lisp structure
  155. (use BPS for vector of 8-bit ints)
  156. 1 0 | 0 0 1 0 | * 0 1 0 vector of 16-bit integers
  157. 1 0 | 0 1 1 0 | * 0 1 0 vector of 32-bit integers
  158. 1 0 | 1 0 1 0 | * 0 1 0 MIXED1 [3 words of pointers, then binary]
  159. 1 0 | 1 1 1 0 | * 0 1 0 MIXED2
  160. 1 1 | 0 0 1 0 | * 0 1 0 vector of single-precision floats
  161. 1 1 | 0 1 1 0 | * 0 1 0 vector of double-precision floats
  162. 1 1 | 1 0 1 0 | * 0 1 0 MIXED3
  163. 1 1 | 1 1 1 0 | * 0 1 0 Stream handle (aka MIXED4)
  164. -------------------------------------------------------------------------------
  165. /* end of doc.h */