Changeset 6547


Ignore:
Timestamp:
May 12, 2007, 11:02:20 PM (15 years ago)
Author:
gb
Message:

Update for 070512.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/ccl/release-notes.txt

    r6246 r6547  
     1OpenMCL 1.1-pre-070512
     2- The FASL version changed (old FASL files won't work with this
     3  lisp version), as did the version information which tries to
     4  keep the kernel in sync with heap images.  Note that it's generally
     5  a lot easier to recompile recent sources with recent images, e.g.,
     6  trying to compile 070512 sources with an 070407 image is unlikely
     7  to work without tricky bootstrapping.
     8- Most of the changes in this release involve the calling sequence
     9  used on x86-64.  In very general terms, some kinds of function-call
     10  intensive code may see a significant performance boost, most code
     11  should see a slight improvement, some code might see a (hopefully
     12  very slight) degradation, and anything significantly slower than
     13  previous releases should be reported as a bug.
     14  It is -possible- that some of these changes may cause errors to
     15  be reported differently (the function reported as the function
     16  executing when the error ocurred might be different/wrong).  I
     17  have not seen as many cases of this as I expected to when making
     18  the change, but am also not sure that I fixed all possible cases.
     19- The FFI-related reader macros #_, #$, and #& all read a case-sensitive
     20  foreign function, constant, or variable name from the input stream
     21  and try to find the corresponding definition in the interface files.
     22  If the name is prefixed with a #\? - as in #_?foo - the macros
     23  return true if the definition could be found and false otherwise.
     24  (The general idea is that this might be useful for conditionalizing
     25  code in some cases, and there should be -some- way of quietly testing
     26  that something's defined.)
     27- There is now support for making the contents of (possibly very large)
     28  files accessible as lisp vectors.  (This may be many times faster
     29  than something like
     30
     31  (let* ((stream (open pathname :direction :input :element-type 'whatever))
     32         (vector (make-array (file-size-to-vector-size stream)
     33                             :element-type 'whatever)))
     34    (read-sequence vector stream))
     35
     36  but has the similar effect of making the contents of VECTOR match the
     37  contents of the file.)
     38
     39  CCL:MAP-FILE-TO-IVECTOR pathname element-type [Function]
     40
     41  "element-type" should be a type specifier such that
     42  (UPGRADED-ARRAY-ELEMENT-TYPE element-type) is a subtype
     43  of either SIGNED-BYTE or UNSIGNED-BYTE.
     44
     45  Tries to open the file named by "pathname" for reading and to
     46  map its contents into the process's address space via #_mmap;
     47  if successful, returns a lisp vector of element-type
     48  (UPGRADED-ARRAY-ELEMENT-TYPE element-type) which is displaced
     49  to an underlying (SIMPLE-ARRAY element-type (*)) whose contents
     50  match the mapped file's.
     51
     52  Because of alignment issues, the mapped file's contents will
     53  start a few bytes (4 bytes on 32-bit platforms, 8 bytes on 64-bit
     54  platforms) "into" the vector; the displaced array returned by
     55  CCL:MAP-FILE-TO-IVECTOR hides this overhead, but its usually
     56  more efficient to operate on the underlying simple 1-dimensional
     57  array.  Given a displaced array (like the value returned by
     58  CCL:MAP-FILE-TO-IVECTOR), the CL function ARRAY-DISPLACEMENT
     59  returns the underlying array and the displacement index in elements.
     60
     61  Currently, only read-only file mapping is supported; the underlying
     62  vector will be allocated in read-only memory, and attempts to use
     63  (e.g.) (SETF (AREF ...) ...) to modify the mapped vector's contents
     64  will result in memory faults.
     65 
     66  CCL:MAP-FILE-TO-OCTET-VECTOR pathname [Function]
     67
     68  Equivalent to (CCL:MAP-FILE-TO-IVECTOR pathname '(UNSIGNED-BYTE 8)).
     69
     70  CCL:UNMAP-IVECTOR displaced-vector
     71
     72  If the argument is a mapped vector (as returned by
     73  MAP-FILE-TO-IVECTOR) that has not yet been "unmapped" by this
     74  function, undoes the memory mapping, closes the mapped file, and
     75  adjusts its argument so that it's displaced to a 0-length vector.
     76
     77  CCL:UNMAP-OCTET-VECTOR is an alias for CCL:UNMAP-IVECTOR
     78
     79  Note that whether a vector's created by MAKE-ARRAY or by mapping
     80  a file's contents, it can't have ARRAY-TOTAL-SIZE-LIMIT or more
     81  elements.  (ARRAY-TOTAL-SIZE-LIMIT is (EXPT 2 24) in 32-bit OpenMCL
     82  and (EXPT 2 56) in 64-bit versions.
     83
     84- The lisp kernel now tries to signal memory faults that occur when
     85  running lisp code as lisp errors.  As a silly example:
     86
     87  ? (defun foo (x)
     88     "Crash and burn if X is not a list"
     89     (declare (optimize (speed 3) (safety 0)) (list x))
     90     (car x))
     91  FOO
     92  ? (foo 0)
     93  > Error: Fault during read of memory address #x4
     94  > While executing: FOO, in process listener(1).
     95
     96  The fact that things are handled this way (rather than going
     97  into the kernel debugger with no easy way of recovering) makes
     98  it possible to continue a session without losing work in many
     99  cases.  In a trivial example like the one above, it's relatively
     100  easy to see that no harm has been done and the error should
     101  not be hard to recover from.  In some other cases, it may be
     102  true that a buggy function has been scribbling ofer memory for
     103  a while before that scribbling resulted in a machine exception.
     104
     105  Moral: if you get an unexpected "memory fault" error (the
     106  condition type is actually CCL::INVALID-MEMORY-ACCESS) and
     107  don't understand why the fault occurred and the consequences
     108  of continuing in the lisp session where the fault occurred,
     109  you should view the state of that session with some suspicion.
     110
     111  Faults in foreign code (should) still trap into the kernel
     112  debugger.  (It'd be nice to be able to treat these as lisp
     113  errors with the same caveats as described above, but that
     114  is more complicated in some cases and isn't yet implemented.)
     115
     116- An obscure kernel debugger command - (A), which tries to advance
     117  the program counter by one instruction - is now disabled on x86-64.
     118  (On the PPC, "one instruction" always meant "4 bytes"; implementing
     119  this correctly on x86-64 would require the ability to at least
     120  partially disassemble arbitrary x86-64 instructions.)
     121
     122  On the other hand, the kernel debugger should be able to show
     123  FPU registers on x86-64.
     124
     125
    1126OpenMCL 1.1-pre-070408
    2127- The FASL version changed (old FASL files won't work with this
Note: See TracChangeset for help on using the changeset viewer.