source: trunk/source/doc/src/modifying.xml @ 9176

Last change on this file since 9176 was 9176, checked in by mikel, 12 years ago

additional mechaincal and style edits in implementation and modifying

File size: 21.6 KB
1<?xml version="1.0" encoding="utf-8"?>
2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "" [
3          <!ENTITY rest "<varname>&amp;rest</varname>">
4          <!ENTITY key "<varname>&amp;key</varname>">
5          <!ENTITY optional "<varname>&amp;optional</varname>">
6          <!ENTITY body "<varname>&amp;body</varname>">
7          <!ENTITY aux "<varname>&amp;aux</varname>">
8          <!ENTITY allow-other-keys "<varname>&amp;allow-other-keys</varname>">
9          <!ENTITY CCL "Clozure CL">
10          ]>
12<chapter id="Modifying-CCL">
13  <title>Modifying &CCL;</title>
15  <sect1 id="Contributing-Code-Back-to-the-CCL-Project">
16    <title>Contributing Code Back to the &CCL; Project</title>
17    <para>This section is a placeholder, added as of August 2004.  The
18      full text is being written, and will be added as soon as it is
19      available.</para>
20  </sect1>
22  <sect1 id="Using-CCL-in--development--and-in--user--mode">
23    <title>Using &CCL; in "development" and in  "user" mode</title>
25    <para>As it's distributed, &CCL; starts up with *PACKAGE* set to
26      the CL-USER package and with most predefined functions and
27      methods protected against accidental redefinition.  The package
28      setting is of course a requirement of ANSI CL, and the
29      protection of predifined functions and methods is intended to
30      catch certain types of programming errors (accidentally
31      redefining a CL or CCL function) before those errors have a
32      chance to do much damage.</para>
33    <para>These settings may make using &CCL; to develop &CCL; a bit
34      awkward, because much of that process assumes you are working in
35      the CCL package is current, and a primary purpose of &CCL;
36      development is to redefine some predefined, builtin functions.
37      The standard, "routine" ways of building &CCL; from sources (see
38      ) - COMPILE-CCL, XCOMPILE-CCL, and XLOAD-LEVEL-0 - bind
39      *PACKAGE* to the "CCL" package and enable the redefinition of
40      predefined functions; the symbols COMPILE-CCL, XCOMPILE-CCL, and
41      XLOAD-LEVEL-0 are additionally now exported from the "CCL"
42      package.</para>
43    <para>Some other (more ad-hoc) ways of doing development on
44      &CCL;&mdash;compiling and/or loading individual files,
45      incrementally redefining individual functions&mdash;may be
46      awkward unless one reverts to the mode of operation which was
47      traditionally offered in &CCL;. Some &CCL; source files -
48      especially those that comprise the bootstrapping image sources
49      and the first few files in the "cold load" sequence - are
50      compiled and loaded in the "CCL" package but don't contain
51      (IN-PACKAGE "CCL") forms, since IN-PACKAGE doesn't work until
52      later in the cold load sequence.</para>
53    <para>The somewhat bizarre behavior of both SET-USER-ENVIRONMENT
54      and SET-DEVELOPMENT-ENVIRONMENT with respect to the special
55      variables they affect is intended to allow those constructs to
56      take effect when the read-eval-print loop next returns to a
57      top-level '? ' prompt; the constructs can meaningfully be used
58      inside LOAD, for instance (recall that LOAD binds *PACKAGE*),
59      though using both constructs within the same LOAD call would
60      likely be pretty confusing.</para>
61    <para>"user" and "development" are otherwise very generic terms;
62      here they're intended to enforce the distinction between "using"
63      &CCL; and "developing" it.</para>
64    <para>The initial environment from which &CCL; images are
65      saved is one where (SET-USER-ENVIRONMENT T) has just been
66      called; in previous versions, it was effectively as if
67      (SET-DEVELOPMENT-ENVIRONMENT T) had just been called.</para>
68    <para>Hopefully, most users of &CCL; can safely ignore these
69      issues most of the time. Note that doing (SET-USER-ENVIRONMENT
70      T) after loading one's own code (or 3rd-party code) into &CCL;
71      would protect that code (as well as &CCL;'s) from accidental
72      redefinition; that may be useful in some cases.</para>
73  </sect1>
75  <sect1 id="kernel-debugger">
76    <title>The Kernel Debugger</title>
77    <para> In a perfect world, something like this couldn't
78      happen:</para>
79    <programlisting>
80Welcome to &CCL; Version x.y!
81? (defun foo (x)
82    (declare (cons x))
83    (cdr x))
86? (foo -1) ;Oops. Too late ...
87Unhandled exception 11 at 0x300e90c8, context->regs at #x7ffff6b8
88Continue/Debugger/eXit &lt;enter&gt;?
89    </programlisting>
91    <para>As you may have noticed, it's not a perfect world; it's rare
92      that the cause (attempting to reference the CDR of -1, and therefore
93      accessing unmapped memory near location 0) of this effect (an
94      "Unhandled exception ..." message) is so obvious.</para>
95    <para>The addresses printed in the message above aren't very useful
96      unless you're debugging the kernel with GDB (and they're often
97      very useful if you are.)</para>
98    <para>Aside from causing an exception that the lisp kernel doesn't
99      know how to handle, one can also enter the kernel debugger (more)
100      deliberately:</para>
102    <programlisting>
103? (defun classify (n)
104    (cond ((&gt; n 0) "Greater")
105          ((&lt; n 0) "Less")
106          (t
107           ;; Sheesh ! What else could it be ?
108           (ccl::bug "I give up. How could this happen ?"))))
111? (classify 0)
112Bug in &CCL; system code:
113I give up. How could this happen ?
114? for help
115[12345] &CCL; kernel debugger:
116    </programlisting>
118    <para>CCL::BUG isn't quite the right tool for this example (a
119      call to BREAK or PRINT might do a better job of clearing up the
120      mystery), but it's sometimes helpful when those other tools
121      can't be used.  The lisp error system notices, for instance, if
122      attempts to signal errors themselves cause errors to be
123      signaled; this sort of thing can happen if CLOS or the I/O
124      system are broken or missing. After some small number of
125      recursive errors, the error system gives up and calls
126      CCL::BUG.</para>
127    <para>If one enters a '?' at the kernel debugger prompt, one
128      will see output like:</para>
130    <programlisting>
131(S)  Find and describe symbol matching specified name
132(B)  Show backtrace
133(X)  Exit from this debugger, asserting that any exception was handled
134(K)  Kill &CCL; process
135(?)  Show this help
136    </programlisting>
138    <para>CCL::BUG just does an FF-CALL into the lisp kernel.  If
139      the kernel debugger was invoked because of an unhandled
140      exception (such as an illegal memory reference) the OS kernel
141      saves the machine state ("context") in a data structure for us,
142      and in that case some additional options can be used to display
143      the contents of the registers at the point of the
144      exception. Another function&mdash;CCL::DBG&mdash;causes a special
145      exception to be generated and enters the lisp kernel debugger
146      with a non-null "context":</para>
148    <programlisting>
149? (defun classify2 (n)
150    (cond ((&gt; n 0) "Greater")
151          ((&lt; n 0) "Less")
152          (t (dbg n))))
155? (classify2 0)
156Lisp Breakpoint
157While executing: #&lt;Function CLASSIFY2 #x08476cfe>
158? for help
159[12345] &CCL; kernel debugger: ?
160(G)  Set specified GPR to new value
161(A)  Advance the program counter by one instruction (use with caution!)
162(D)  Describe the current exception in greater detail
163(R)  Show raw GPR/SPR register values
164(L)  Show Lisp values of tagged registers
165(F)  Show FPU registers
166(S)  Find and describe symbol matching specified name
167(B)  Show backtrace
168(X)  Exit from this debugger, asserting that any exception was handled
169(P)  Propagate the exception to another handler (debugger or OS)
170(K)  Kill &CCL; process
171(?)  Show this help
172    </programlisting>
174    <para>CCL::DBG takes an argument, whose value is copied into the register
175      that &CCL; uses to return a function's primary value (arg_z, which
176      is r23 on the PowerPC). If we were to choose the (L) option at this point,
177      we'd see a dislay like:</para>
179    <programlisting>
180rnil = 0x01836015
181nargs = 0
182r16 (fn) = #&lt;Function CLASSIFY2 #x30379386>
183r23 (arg_z) = 0
184r22 (arg_y) = 0
185r21 (arg_x) = 0
186r20 (temp0) = #&lt;26-element vector subtag = 2F @#x303793ee>
187r19 (temp1/next_method_context) = 6393788
188r18 (temp2/nfn) = #&lt;Function CLASSIFY2 #x30379386>
189r17 (temp3/fname) = CLASSIFY2
190r31 (save0) = 0
191r30 (save1) = *TERMINAL-IO*
192r29 (save2) = 0
193r28 (save3) = (#&lt;RESTART @#x01867f2e> #&lt;RESTART @#x01867f56>)
194r27 (save4) = ()
195r26 (save5) = ()
196r25 (save6) = ()
197r24 (save7) = ()
198    </programlisting>
200    <para>From this we can conclude that the problematic argument to CLASSIFY2
201      was 0 (see r23/arg_z), and that I need to work on a better example.</para>
202    <para>The R option shows the values of the ALU (and PPC branch unit)
203      registers in hex; the F option shows the values of the FPU registers.</para>
204    <para>The (B) option shows a raw stack backtrace; it'll try to
205      identify foreign functions as well as lisp functions. (Foreign function
206      names are guesses based on the nearest preceding exported symbol.)</para>
207    <para>If you ever unexpectedly find yourself in the "lisp kernel
208      debugger", the output of the (L) and (B) options are often the most
209      helpful things to include in a bug report.</para>
210  </sect1>
212  <sect1 id="Using-AltiVec-in-CCL-LAP-functions">
213    <title>Using AltiVec in &CCL; LAP functions</title>
215    <sect2 id="Overview--16-">
216          <title>Overview</title>
217      <para>It's now possible to use AltiVec instructions in PPC LAP
218        (assembler) functions.</para>
219      <para>The lisp kernel detects the presence or absence of
220        AltiVec and preserves AltiVec state on lisp thread switch and
221        in response to exceptions, but the implementation doesn't
222        otherwise use vector operations.</para>
223      <para>This document doesn't document PPC LAP programming in
224        general.  Ideally, there would be some document that
225        did.</para>
226      <para>This document does explain AltiVec register-usage
227        conventions in &CCL; and explains the use of some lap macros
228        that help to enforce those conventions.</para>
229      <para>All of the global symbols described below are exported
230        from the CCL package. Note that lap macro names, ppc
231        instruction names, and (in most cases) register names are
232        treated as strings, so this only applies to functions and
233        global variable names.</para>
234      <para>Much of the &CCL; support for AltiVec LAP programming
235        is based on work contributed to MCL by Shannon Spires.</para>
236    </sect2>
238    <sect2 id="Register-usage-conventions">
239          <title>Register usage conventions</title>
240      <para>&CCL; LAP functions that use AltiVec instructions must
241        interoperate with each other and with C functions; that fact
242        suggests that they follow C AltiVec register usage
243        conventions. (vr0-vr1 scratch, vr2-vr13 parameters/return
244        value, vr14-vr19 temporaries, vr20-vr31 callee-save
245        non-volatile registers.)</para>
246      <para>The EABI (Embedded Application Binary Interface) used in
247        LinuxPPC doesn't ascribe particular significance to the vrsave
248        special-purpose register; on other platforms (notably MacOS),
249        it's used as a bitmap which indicates to system-level code
250        which vector registers contain meaningful values.</para>
251      <para>The WITH-ALTIVEC-REGISTERS lap macro generates code that
252        saves, updates, and restores VRSAVE on platforms where this is
253        required (as indicated by the value of the special variable
254        that controls this behavior) and ignores VRSAVE on platforms
255        that don't require it to be maintained.</para>
256      <para>On all PPC platforms, it's necessary to save any non-volatile
257        vector registers (vr20 .. vr31) before assigning to them and to restore
258        such registers before returning to the caller.</para>
259      <para>On platforms that require that VRSAVE be maintained, it's
260        not necessary to mention the "use" of vector registers that
261        are used as incoming parameters. It's not incorrect to mention
262        their use in a WITH-ALTIVEC-REGISTERS form, but it may be
263        unnecessary in many interesting cases. One can likewise assume
264        that the caller of any function that returns a vector value in
265        vr2 has already set the appropriate bit in VRSAVE to indicate
266        that this register is live. One could therefore write a leaf
267        function that added the bytes in vr3 and vr2 and returned the
268        result in vr2 as:</para>
270      <programlisting>
271(defppclapfunction vaddubs ((y vr3) (z vr2))
272  (vaddubs z y z)
273  (blr))
274      </programlisting>
276      <para>When vector registers that aren't incoming parameters are used
277        in a LAP function, WITH-ALTIVEC-REGISTERS takes care of maintaining VRSAVE
278        and of saving/restoring any non-volatile vector registers:</para>
280      <programlisting>
281(defppclapfunction load-array ((n arg_z))
282  (check-nargs 1)
283  (with-altivec-registers (vr1 vr2 vr3 vr27) ; Clobbers imm0
284    (li imm0 arch::misc-data-offset)
285    (lvx vr1 arg_z imm0)                ; load MSQ
286    (lvsl vr27 arg_z imm0)              ; set the permute vector
287    (addi imm0 imm0 16)                 ; address of LSQ
288    (lvx vr2 arg_z imm0)                ; load LSQ
289    (vperm vr3 vr1 vr2 vr27)           ; aligned result appears in VR3
290    (dbg t))                         ; Look at result in some debugger
291  (blr))
292      </programlisting>
294      <para>AltiVec registers are not preserved by CATCH and UNWIND-PROTECT.
295        Since AltiVec is only accessible from LAP in &CCL; and since LAP
296        functions rarely use high-level control structures, this should rarely be
297        a problem in practice.</para>
298      <para>LAP functions that use non-volatile vector registers and
299        that call (Lisp ?) code which may use CATCH or UNWIND-PROTECT
300        should save those vector registers before such a call and
301        restore them on return. This is one of the intended uses of
302        the WITH-VECTOR-BUFFER lap macro.</para>
303    </sect2>
304  </sect1>
306  <sect1 id="Development-Mode-Dictionary">
307    <title>Development-Mode Dictionary</title>
309    <refentry id="v_warn-if-redefine-kernel">
310          <indexterm zone="v_warn-if-redefine-kernel">
311            <primary>*warn-if-redefine-kernel</primary>
312          </indexterm>
314          <refnamediv>
315            <refname>*WARN-IF-REDEFINE-KERNEL*</refname>
316            <refpurpose></refpurpose>
317            <refclass>Variable</refclass>
318          </refnamediv>
320          <refsect1>
321            <title>Description</title>
323            <para>When true, attempts to redefine (via DEFUN or DEFMETHOD)
324              functions and methods that are marked as being
325              &#34;predefined&#34; signal continuable errors.</para>
327            <para>Note that these are CERRORs, not warnings, and that
328              no lisp functions or methods have been defined in the kernel
329              in MCL or &CCL; since 1987 or so.</para>
330          </refsect1>
331    </refentry>
333    <refentry id="f_set-development-environment">
334          <indexterm zone="f_set-development-environment">
335            <primary>set-development-environment</primary>
336          </indexterm>
338          <refnamediv>
339            <refname>SET-DEVELOPMENT-ENVIRONMENT</refname>
340            <refpurpose></refpurpose>
341            <refclass>Function</refclass>
342          </refnamediv>
344          <refsynopsisdiv>
345            <synopsis><function>set-development-environment</function>
346              &optional;
347              unmark-builtin-functions</synopsis>
348          </refsynopsisdiv>
350          <refsect1>
351            <title>Description</title>
353            <para>Arranges that the outermost special bindings of *PACKAGE*
354              and *WARN-IF-REDEFINE-KERNEL* restore values of the &#34;CCL&#34;
355              package and NIL to these variables, respectively. If the optional
356              argument is true, marks all globally defined functions and methods
357              as being &#34;not predefined&#34; (this is a fairly expensive
358              operation.)</para>
359          </refsect1>
360    </refentry>
362    <refentry id="f_set-user-environment">
363          <indexterm zone="f_set-user-environment">
364            <primary>set-user-environment</primary>
365          </indexterm>
367          <refnamediv>
368            <refname>SET-USER-ENVIRONMENT</refname>
369            <refpurpose></refpurpose>
370            <refclass>Function</refclass>
371          </refnamediv>
373          <refsynopsisdiv>
374            <synopsis><function>set-user-environment</function>
375              &optional; mark-builtin-functions</synopsis>
376          </refsynopsisdiv>
378          <refsect1>
379            <title>Description</title>
381            <para>Arranges that the outermost special bindings of *PACKAGE*
382              and *WARN-IF-REDEFINE-KERNEL* restore values of the
383              &#34;CL-USER&#34; package and T to these variables, respectively.
384              If the optional argument is true, marks all globally defined
385              functions and methods as being &#34;predefined&#34; (this is a
386              fairly expensive operation.)</para>
387          </refsect1>
388    </refentry>
389    <refentry id="v_altivec-available">
390          <indexterm zone="v_altivec-available">
391            <primary>*altivec-available*</primary>
392          </indexterm>
394          <refnamediv>
395            <refname>*ALTIVEC-AVAILABLE*</refname>
396            <refpurpose></refpurpose>
397            <refclass>Variable</refclass>
398          </refnamediv>
400          <refsect1>
401            <title>Description</title>
402            <para>This variable is initialized each time an &CCL; session
403              starts based on information provided by the lisp kernel. Its value
404              is true if AltiVec is present and false otherwise. This variable
405              shouldn't be set by user code.</para>
406          </refsect1>
407    </refentry>
409    <refentry id="f_altivec-available-p">
410          <indexterm zone="f_altivec-available-p">
411            <primary>altivec-available-p</primary>
412          </indexterm>
414          <refnamediv>
415            <refname>ALTIVEC-AVAILABLE-P</refname>
416            <refpurpose></refpurpose>
417            <refclass>Function</refclass>
418          </refnamediv>
420          <refsynopsisdiv>
421            <synopsis><function>altivec-available-p</function></synopsis>
422          </refsynopsisdiv>
424          <refsect1>
425            <title>Description</title>
427            <para>Returns non-NIL if AltiVec is available.</para>
428          </refsect1>
429    </refentry>
431    <refentry id="v_altivec-lapmacros-maintain-vrsave-p">
432          <indexterm zone="v_altivec-lapmacros-maintain-vrsave-p">
433            <primary>*altivec-lapmacros-maintain-vrsave-p*</primary>
434          </indexterm>
436          <refnamediv>
437            <refname>*ALTIVEC-LAPMACROS-MAINTAIN-VRSAVE-P*</refname>
438            <refpurpose></refpurpose>
439            <refclass>Variable</refclass>
440          </refnamediv>
442          <refsect1>
443            <title>Description</title>
445            <para>Intended to control the expansion of certain lap macros.
446              Initialized to NIL on LinuxPPC; initialized to T on platforms
447              (such as MacOS X/Darwin) that require that the VRSAVE SPR contain
448              a bitmask of active vector registers at all times.</para>
449          </refsect1>
450    </refentry>
452    <refentry id="lapm_with-altivec-registers">
453          <indexterm zone="lapm_with-altivec-registers">
454            <primary>with-altivec-registers</primary>
455          </indexterm>
457          <refnamediv>
458            <refname>WITH-ALTIVEC-REGISTERS</refname>
459            <refpurpose></refpurpose>
460            <refclass>LAP Macro</refclass>
461          </refnamediv>
463          <refsynopsisdiv>
464            <synopsis><function>with-altivec-registers</function>
465              reglist &body; body</synopsis>
466          </refsynopsisdiv>
468          <refsect1>
469            <title>Arguments and Values</title>
471            <variablelist>
472              <varlistentry>
473                <term>reglist</term>
475                <listitem>
476                      <para>A list of vector register names (vr0 .. vr31).</para>
477                </listitem>
478              </varlistentry>
480              <varlistentry>
481                <term>body</term>
483                <listitem>
484                      <para>A sequence of PPC LAP instructions.</para>
485                </listitem>
486              </varlistentry>
487            </variablelist>
488          </refsect1>
490          <refsect1>
491            <title>Description</title>
493            <para>Specifies the set of AltiVec registers used in body. If
494              *altivec-lapmacros-maintain-vrsave-p* is true when the macro is
495              expanded, generates code to save the VRSAVE SPR and updates VRSAVE
496              to include a bitmask generated from the specified register list.
497              Generates code which saves any non-volatile vector registers which
498              appear in the register list, executes body, and restores the saved
499              non-volatile vector registers (and, if
500              *altivec-lapmacros-maintain-vrsave-p* is true, restores VRSAVE as
501              well. Uses the IMM0 register (r3) as a temporary.</para>
502          </refsect1>
503    </refentry>
505    <refentry id="lapm_with-vector-buffer">
506          <indexterm zone="lapm_with-vector-buffer">
507            <primary>with-vector-buffer</primary>
508          </indexterm>
510          <refnamediv>
511            <refname>WITH-VECTOR-BUFFER</refname>
512            <refpurpose></refpurpose>
513            <refclass>LAP Macro</refclass>
514          </refnamediv>
516          <refsynopsisdiv>
517            <synopsis>with-vector-buffer base n &body; body</synopsis>
518          </refsynopsisdiv>
520          <refsect1>
521            <title>Arguments and Values</title>
523            <variablelist>
524              <varlistentry>
525                <term>base</term>
527                <listitem>
528                      <para>Any available general-purpose register.</para>
529                </listitem>
530              </varlistentry>
532              <varlistentry>
533                <term>n</term>
535                <listitem>
536                      <para>An integer between 1 and 254, inclusive. (Should
537                        typically be much, much closer to 1.) Specifies the size of
538                        the buffer, in 16-byte units.</para>
539                </listitem>
540              </varlistentry>
542              <varlistentry>
543                <term>body</term>
545                <listitem>
546                      <para>A sequence of PPC LAP instructions.</para>
547                </listitem>
548              </varlistentry>
549            </variablelist>
550          </refsect1>
552          <refsect1>
553            <title>Description</title>
554            <para>Generates code which allocates a 16-byte aligned buffer
555              large enough to contain N vector registers; the GPR base points to
556              the lowest address of this buffer. After processing body, the
557              buffer will be deallocated. The body should preserve the value of
558              base as long as it needs to reference the buffer. It's
559              intended that base be used as a base register in stvx and lvx
560              instructions within the body.</para>
561          </refsect1>
562    </refentry>
563  </sect1>
Note: See TracBrowser for help on using the repository browser.