diff --git a/docs/cmu-user/extensions.tex b/docs/cmu-user/extensions.tex index da38eafc31911c6c1da4c0205ac3913ea5f884d8..5e61c0b46b025f824e20f430ef3d37d3056bd0c0 100644 --- a/docs/cmu-user/extensions.tex +++ b/docs/cmu-user/extensions.tex @@ -2465,6 +2465,12 @@ innermost fwrapper. \section{Dynamic-Extent Declarations} \cindex{dynamic-extent} +\emph{Note: As of the 19a release, \code{dynamic-extent} is + unfortunately disabled by default. It is known to cause some issues + with CLX and Hemlock. The cause is not known, but causes random + errors and brokeness. Enable at your own risk. However, it is safe + enough for build all of CMUCL without problems.} + On x86 and sparc, \cmucl{} can exploit \code{dynamic-extent} declarations by allocating objects on the stack instead of the heap. @@ -2565,3 +2571,48 @@ Please note that the \code{setq} of \code{x} in the example program assigns to \code{x} a list that is allocated from the heap. This is another arbitrary restriction that exists because other Lisps behave that way. + +\section{Modular Arithmetic} +\cindex{modular-arith} + +This section is mostly taken, with permission, from the documentation +for SBCL. + +Some numeric functions have a property: \code{N} lower bits of +the result depend only on \code{N} lower bits of (all or some) +arguments. If the compiler sees an expression of form \code{(logand +exp mask)}, where \code{exp} is a tree of such ``good'' functions +and \code{mask} is known to be of type \code{(unsigned-byte +w)}, where \code{w} is a "good" width, all intermediate results +will be cut to \code{w} bits (but it is not done for variables +and constants!). This often results in an ability to use simple +machine instructions for the functions. + +Consider an example. +\begin{lisp} +(defun i (x y) + (declare (type (unsigned-byte 32) x y)) + (ldb (byte 32 0) (logxor x (lognot y)))) +\end{lisp} +The result of \code{(lognot y)} will be negative and of +type \code{(signed-byte 33)}, so a naive implementation on a 32-bit +platform is unable to use 32-bit arithmetic here. But modular +arithmetic optimizer is able to do it: because the result is cut down +to 32 bits, the compiler will replace \code{logxor} +and \code{lognot} with versions cutting results to 32 bits, and +because terminals (here---expressions \code{x} and \code{y}) +are also of type \code{(unsigned-byte 32)}, 32-bit machine +arithmetic can be used. + + +Currently ``good'' functions +are \code{+}, \code{-}, \code{*}; \code{logand}, \code{logior}, +\code{logxor}, \code{lognot} and their combinations; +and \code{ash} with the positive second argument. ``Good'' widths +are 32 on HPPA, MIPS, PPC, Sparc and X86 and 64 on Alpha. While it is +possible to support smaller widths as well, currently it is not +implemented. + +A more extensive description of modular arithmetic can be found in the +paper ``Efficient Hardware Arithmetic in Common Lisp'' by Alexey +Dejneka, and Christophe Rhodes, to be published.