![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ch12.r CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 42BSD / ucb / lisp / lisplib / manual|
Return to ch12.r CVS log | Up to [CSRG BSD Unix] / 42BSD / ucb / lisp / lisplib / manual |
1.1 root 1:
2:
3:
4:
5:
6:
7:
8: CHAPTER 12
9:
10:
11: Liszt - the lisp compiler
12:
13:
14:
15:
16:
17:
18: 12.1. General strategy of the compiler
19:
20: The purpose of the lisp compiler, Liszt, is to
21: create an object module which when brought into the
22: lisp system using _f_a_s_l will have the same effect as
23: bringing in the corresponding lisp coded source module
24: with _l_o_a_d with one important exception, functions will
25: be defined as sequences of machine language instruc-
26: tions, instead of lisp S-expressions. Liszt is not a
27: function compiler, it is a _f_i_l_e compiler. Such a file
28: can contain more than function definitions; it can
29: contain other lisp S-expressions which are evaluated
30: at load time. These other S-expressions will also be
31: stored in the object module produced by Liszt and will
32: be evaluated at fasl time.
33:
34: As is almost universally true of Lisp compilers,
35: the main pass of Liszt is written in Lisp. A subse-
36: quent pass is the assembler, for which we use the
37: standard UNIX assembler.
38:
39:
40:
41: 12.2. Running the compiler
42:
43: The compiler is normally run in this manner:
44: % liszt foo
45: will compile the file foo.l or foo (the preferred way
46: to indicate a lisp source file is to end the file name
47: with `.l'). The result of the compilation will be
48: placed in the file foo.o if no fatal errors were
49: detected. All messages which Liszt generates go to
50: the standard output. Normally each function name is
51: printed before it is compiled (the -q option
52: suppresses this).
53:
54:
55:
56: 12.3. Special forms
57:
58: Liszt makes one pass over the source file. It
59: processes each form in this way:
60: 9
61:
62: 9Liszt - the lisp compiler 12-1
63:
64:
65:
66:
67:
68:
69:
70: Liszt - the lisp compiler 12-2
71:
72:
73: 12.3.1. macro expansion
74:
75: If the form is a macro invocation (i.e it is a
76: list whose car is a symbol whose function binding
77: is a macro), then that macro invocation is
78: expanded. This is repeated until the top level
79: form is not a macro invocation. When Liszt begins,
80: there are already some macros defined, in fact some
81: functions (such as defun) are actually macros. The
82: user may define his own macros as well. For a
83: macro to be used it must be defined in the Lisp
84: system in which Liszt runs.
85:
86:
87:
88: 12.3.2. classification
89:
90: After all macro expansion is done, the form is
91: classified according to its _c_a_r (if the form is not
92: a list, then it is classified as an _o_t_h_e_r).
93:
94:
95:
96: 12.3.2.1. eval-when
97:
98: The form of eval-when is (_e_v_a_l-
99: _w_h_e_n (_t_i_m_e_1 _t_i_m_e_2 ...) _f_o_r_m_1 _f_o_r_m_2 ...) where
100: the time_i are one of _e_v_a_l, _c_o_m_p_i_l_e, or _l_o_a_d.
101: The compiler examines the form_i in sequence and
102: the action taken depends on what is in the time
103: list. If _c_o_m_p_i_l_e is in the list then the com-
104: piler will invoke _e_v_a_l on each form_i as it exam-
105: ines it. If _l_o_a_d is in the list then the com-
106: pile will recursively call itself to compile
107: each form_i as it examines it. Note that if _c_o_m_-
108: _p_i_l_e and _l_o_a_d are in the time list, then the
109: compiler will both evaluate and compile each
110: form. This is useful if you need a function to
111: be defined in the compiler at both compile time
112: (perhaps to aid macro expansion) and at run time
113: (after the file is _f_a_s_led in).
114:
115:
116:
117: 12.3.2.2. declare
118:
119: Declare is used to provide information
120: about functions and variables to the compiler.
121: It is (almost) equivalent to (_e_v_a_l-
122: _w_h_e_n (_c_o_m_p_i_l_e) ...). You may declare functions
123: to be one of three types: lambda (*expr),
124: nlambda (*fexpr), lexpr (*lexpr). The names in
125: parenthesis are the Maclisp names and are
126:
127:
128: Printed: August 5, 1983
129:
130:
131:
132:
133:
134:
135:
136: Liszt - the lisp compiler 12-3
137:
138:
139: accepted by the compiler as well (and not just
140: when the compiler is in Maclisp mode). Func-
141: tions are assumed to be lambdas until they are
142: declared otherwise or are defined differently.
143: The compiler treats calls to lambdas and lexprs
144: equivalently, so you needn't worry about declar-
145: ing lexprs either. It is important to declare
146: nlambdas or define them before calling them.
147: Another attribute you can declare for a function
148: is localf which makes the function `local'. A
149: local function's name is known only to the func-
150: tions defined within the file itself. The
151: advantage of a local function is that is can be
152: entered and exited very quickly and it can have
153: the same name as a function in another file and
154: there will be no name conflict.
155:
156: Variables may be declared special or unspe-
157: cial. When a special variable is lambda bound
158: (either in a lambda, prog or do expression), its
159: old value is stored away on a stack for the
160: duration of the lambda, prog or do expression.
161: This takes time and is often not necessary.
162: Therefore the default classification for vari-
163: ables is unspecial. Space for unspecial vari-
164: ables is dynamically allocated on a stack. An
165: unspecial variable can only be accessed from
166: within the function where it is created by its
167: presence in a lambda, prog or do expression
168: variable list. It is possible to declare that
169: all variables are special as will be shown
170: below.
171:
172: You may declare any number of things in
173: each declare statement. A sample declaration is
174: (_d_e_c_l_a_r_e
175: (_l_a_m_b_d_a _f_u_n_c_1 _f_u_n_c_2)
176: (*_f_e_x_p_r _f_u_n_c_3)
177: (*_l_e_x_p_r _f_u_n_c_4)
178: (_l_o_c_a_l_f _f_u_n_c_5)
179: (_s_p_e_c_i_a_l _v_a_r_1 _v_a_r_2 _v_a_r_3)
180: (_u_n_s_p_e_c_i_a_l _v_a_r_4))
181:
182: You may also declare all variables to be
183: special with (_d_e_c_l_a_r_e (_s_p_e_c_i_a_l_s _t)). You may
184: declare that macro definitions should be com-
185: piled as well as evaluated at compile time by
186: (_d_e_c_l_a_r_e (_m_a_c_r_o_s _t)). In fact, as was mentioned
187: above, declare is much like (_e_v_a_l-
188: _w_h_e_n (_c_o_m_p_i_l_e) ...). Thus if the compiler sees
189: (_d_e_c_l_a_r_e (_f_o_o _b_a_r)) and foo is defined, then it
190: will evaluate (_f_o_o _b_a_r). If foo is not defined
191: then an undefined declare attribute warning will
192:
193:
194: Printed: August 5, 1983
195:
196:
197:
198:
199:
200:
201:
202: Liszt - the lisp compiler 12-4
203:
204:
205: be issued.
206:
207:
208:
209: 12.3.2.3. (progn 'compile form1 form2 ... formn)
210:
211: When the compiler sees this it simply com-
212: piles form1 through formn as if they too were
213: seen at top level. One use for this is to allow
214: a macro at top-level to expand into more than
215: one function definition for the compiler to com-
216: pile.
217:
218:
219:
220: 12.3.2.4. include/includef
221:
222: _I_n_c_l_u_d_e and _i_n_c_l_u_d_e_f cause another file to
223: be read and compiled by the compiler. The
224: result is the same as if the included file were
225: textually inserted into the original file. The
226: only difference between _i_n_c_l_u_d_e and _i_n_c_l_u_d_e_f is
227: that include doesn't evaluate its argument and
228: includef does. Nested includes are allowed.
229:
230:
231:
232: 12.3.2.5. def
233:
234: A def form is used to define a function.
235: The macros _d_e_f_u_n and _d_e_f_m_a_c_r_o expand to a def
236: form. If the function being defined is a
237: lambda, nlambda or lexpr then the compiler con-
238: verts the lisp definition to a sequence of
239: machine language instructions. If the function
240: being defined is a macro, then the compiler will
241: evaluate the definition, thus defining the macro
242: withing the running Lisp compiler. Furthermore,
243: if the variable _m_a_c_r_o_s is set to a non nil
244: value, then the macro definition will also be
245: translated to machine language and thus will be
246: defined when the object file is fasled in. The
247: variable _m_a_c_r_o_s is set to t by
248: (_d_e_c_l_a_r_e (_m_a_c_r_o_s _t)).
249:
250: When a function or macro definition is com-
251: piled, macro expansion is done whenever possi-
252: ble. If the compiler can determine that a form
253: would be evaluated if this function were inter-
254: preted then it will macro expand it. It will
255: not macro expand arguments to a nlambda unless
256: the characteristics of the nlambda is known (as
257: is the case with _c_o_n_d). The map functions (
258:
259:
260: Printed: August 5, 1983
261:
262:
263:
264:
265:
266:
267:
268: Liszt - the lisp compiler 12-5
269:
270:
271: _m_a_p, _m_a_p_c, _m_a_p_c_a_r, and so on) are expanded to a
272: _d_o statement. This allows the first argument to
273: the map function to be a lambda expression which
274: references local variables of the function being
275: defined.
276:
277:
278:
279: 12.3.2.6. other forms
280:
281: All other forms are simply stored in the
282: object file and are evaluated when the file is
283: _f_a_s_led in.
284:
285:
286:
287: 12.4. Using the compiler
288:
289: The previous section describes exactly what the
290: compiler does with its input. Generally you won't
291: have to worry about all that detail as files which
292: work interpreted will work compiled. Following is a
293: list of steps you should follow to insure that a file
294: will compile correctly.
295:
296: [1] Make sure all macro definitions precede their use
297: in functions or other macro definitions. If you
298: want the macros to be around when you _f_a_s_l in the
299: object file you should include this statement at
300: the beginning of the file: (_d_e_c_l_a_r_e (_m_a_c_r_o_s _t))
301:
302: [2] Make sure all nlambdas are defined or declared
303: before they are used. If the compiler comes
304: across a call to a function which has not been
305: defined in the current file, which does not
306: currently have a function binding, and whose type
307: has not been declared then it will assume that
308: the function needs its arguments evaluated (i.e.
309: it is a lambda or lexpr) and will generate code
310: accordingly. This means that you do not have to
311: declare nlambda functions like _s_t_a_t_u_s since they
312: have an nlambda function binding.
313:
314: [3] Locate all variables which are used for communi-
315: cating values between functions. These variables
316: must be declared special at the beginning of a
317: file. In most cases there won't be many special
318: declarations but if you fail to declare a vari-
319: able special that should be, the compiled code
320: could fail in mysterious ways. Let's look at a
321: common problem, assume that a file contains just
322: these three lines:
323: 9
324:
325: 9 Printed: August 5, 1983
326:
327:
328:
329:
330:
331:
332:
333: Liszt - the lisp compiler 12-6
334:
335:
336: (_d_e_f _a_a_a (_l_a_m_b_d_a (_g_l_o_b _l_o_c) (_b_b_b _l_o_c)))
337: (_d_e_f _b_b_b (_l_a_m_b_d_a (_m_y_l_o_c) (_a_d_d _g_l_o_b _m_y_l_o_c)))
338: (_d_e_f _c_c_c (_l_a_m_b_d_a (_g_l_o_b _l_o_c) (_b_b_b _l_o_c)))
339:
340:
341: We can see that if we load in these two defini-
342: tions then (aaa 3 4) is the same as (add 3 4) and
343: will give us 7. Suppose we compile the file con-
344: taining these definitions. When Liszt compiles
345: aaa, it will assume that both glob and loc are
346: local variables and will allocate space on the
347: temporary stack for their values when aaa is
348: called. Thus the values of the local variables
349: glob and loc will not affect the values of the
350: symbols glob and loc in the Lisp system. Now
351: Liszt moves on to function bbb. Myloc is assumed
352: to be local. When it sees the add statement, it
353: find a reference to a variable called glob. This
354: variable is not a local variable to this function
355: and therefore glob must refer to the value of the
356: symbol glob. Liszt will automatically declare
357: glob to be special and it will print a warning to
358: that effect. Thus subsequent uses of glob will
359: always refer to the symbol glob. Next Liszt com-
360: piles ccc and treats glob as a special and loc as
361: a local. When the object file is _f_a_s_l'ed in, and
362: (ccc 3 4) is evaluated, the symbol glob will be
363: lambda bound to 3 bbb will be called and will
364: return 7. However (aaa 3 4) will fail since when
365: bbb is called, glob will be unbound. What should
366: be done here is to put (_d_e_c_l_a_r_e (_s_p_e_c_i_a_l _g_l_o_b) at
367: the beginning of the file.
368:
369: [4] Make sure that all calls to _a_r_g are within the
370: lexpr whose arguments they reference. If _f_o_o is
371: a compiled lexpr and it calls _b_a_r then _b_a_r cannot
372: use _a_r_g to get at _f_o_o's arguments. If both _f_o_o
373: and _b_a_r are interpreted this will work however.
374: The macro _l_i_s_t_i_f_y can be used to put all of some
375: of a lexprs arguments in a list which then can be
376: passed to other functions.
377:
378:
379:
380: 12.5. Compiler options
381:
382: The compiler recognizes a number of options which
383: are described below. The options are typed anywhere
384: on the command line preceded by a minus sign. The
385: entire command line is scanned and all options
386: recorded before any action is taken. Thus
387: % liszt -mx foo
388: % liszt -m -x foo
389:
390:
391: Printed: August 5, 1983
392:
393:
394:
395:
396:
397:
398:
399: Liszt - the lisp compiler 12-7
400:
401:
402: % liszt foo -mx
403: are all equivalent. Before scanning the command line
404: for options, liszt looks for in the environment for
405: the variable LISZT, and if found scans its value as if
406: it was a string of options. The meaning of the
407: options are:
408:
409: C The assembler language output of the compiler is
410: commented. This is useful when debugging the
411: compiler and is not normally done since it slows
412: down compilation.
413:
414: I The next command line argument is taken as a
415: filename, and loaded prior to compilation.
416:
417: e Evaluate the next argument on the command line
418: before starting compilation. For example
419: % liszt -e '(setq foobar "foo string")' foo
420: will evaluate the above s-expression. Note that
421: the shell requires that the arguments be sur-
422: rounded by single quotes.
423:
424: i Compile this program in interlisp compatibility
425: mode. This is not implemented yet.
426:
427: m Compile this program in Maclisp mode. The reader
428: syntax will be changed to the Maclisp syntax and
429: a file of macro definitions will be loaded in
430: (usually named /usr/lib/lisp/machacks). This
431: switch brings us sufficiently close to Maclisp to
432: allow us to compile Macsyma, a large Maclisp pro-
433: gram. However Maclisp is a moving target and we
434: can't guarantee that this switch will allow you
435: to compile any given program.
436:
437: o Select a different object or assembler language
438: file name. For example
439: % liszt foo -o xxx.o
440: will compile foo and into xxx.o instead of the
441: default foo.o, and
442: % liszt bar -S -o xxx.s
443: will compile to assembler language into xxx.s
444: instead of bar.s.
445:
446: p place profiling code at the beginning of each
447: non-local function. If the lisp system is also
448: created with profiling in it, this allows func-
449: tion calling frequency to be determined (see
450: _p_r_o_f(_1))
451:
452: q Run in quiet mode. The names of functions being
453: compiled and various "Note"'s are not printed.
454: 9
455:
456: 9 Printed: August 5, 1983
457:
458:
459:
460:
461:
462:
463:
464: Liszt - the lisp compiler 12-8
465:
466:
467: Q print compilation statistics and warn of strange
468: constructs. This is the inverse of the q switch
469: and is the default.
470:
471: r place bootstrap code at the beginning of the
472: object file, which when the object file is exe-
473: cuted will cause a lisp system to be invoked and
474: the object file _f_a_s_led in. This is known as
475: `autorun' and is described below.
476:
477: S Create an assembler language file only.
478: % liszt -S foo
479: will create the file assembler language file
480: foo.s and will not attempt to assemble it. If
481: this option is not specified, the assembler
482: language file will be put in the temporary disk
483: area under a automatically generated name based
484: on the lisp compiler's process id. Then if there
485: are no compilation errors, the assembler will be
486: invoked to assemble the file.
487:
488: T Print the assembler language output on the stan-
489: dard output file. This is useful when debugging
490: the compiler.
491:
492: u Run in UCI-Lisp mode. The character syntax is
493: changed to that of UCI-Lisp and a UCI-Lisp compa-
494: tibility package of macros is read in.
495:
496: w Suppress warning messages.
497:
498: x Create an cross reference file.
499: % liszt -x foo
500: not only compiles foo into foo.o but also gen-
501: erates the file foo.x . The file foo.x is lisp
502: readable and lists for each function all func-
503: tions which that function could call. The pro-
504: gram lxref reads one or more of these ".x" files
505: and produces a human readable cross reference
506: listing.
507:
508:
509:
510: 12.6. autorun
511:
512: The object file which liszt writes does not con-
513: tain all the functions necessary to run the lisp pro-
514: gram which was compiled. In order to use the object
515: file, a lisp system must be started and the object
516: file _f_a_s_led in. When the -r switch is given to liszt,
517: the object file created will contain a small piece of
518: bootstrap code at the beginning, and the object file
519: will be made executable. Now, when the name of the
520:
521:
522: Printed: August 5, 1983
523:
524:
525:
526:
527:
528:
529:
530: Liszt - the lisp compiler 12-9
531:
532:
533: object file is given to the UNIX command interpreter
534: (shell) to run, the bootstrap code at the beginning of
535: the object file will cause a lisp system to be started
536: and the first action the lisp system will take is to
537: _f_a_s_l in the object file which started it. In effect
538: the object file has created an environment in which it
539: can run.
540:
541: Autorun is an alternative to _d_u_m_p_l_i_s_p. The
542: advantage of autorun is that the object file which
543: starts the whole process is typically small, whereas
544: the minimum _d_u_m_p_l_i_s_ped file is very large (one half
545: megabyte). The disadvantage of autorun is that the
546: file must be _f_a_s_led into a lisp each time it is used
547: whereas the file which _d_u_m_p_l_i_s_p creates can be run as
548: is. liszt itself is a _d_u_m_p_l_i_s_ped file since it is
549: used so often and is large enough that too much time
550: would be wasted _f_a_s_ling it in each time it was used.
551: The lisp cross reference program, lxref, uses _a_u_t_o_r_u_n
552: since it is a small and rarely used program.
553:
554: In order to have the program _f_a_s_led in begin exe-
555: cution (rather than starting a lisp top level), the
556: value of the symbol user-top-level should be set to
557: the name of the function to get control. An example
558: of this is shown next.
559:
560:
561:
562:
563:
564:
565:
566:
567:
568:
569:
570:
571:
572:
573:
574:
575:
576:
577:
578:
579:
580:
581:
582:
583:
584:
585: 9
586:
587: 9 Printed: August 5, 1983
588:
589:
590:
591:
592:
593:
594:
595: Liszt - the lisp compiler 12-10
596:
597:
598:
599: ____________________________________________________
600:
601: _w_e _w_a_n_t _t_o _r_e_p_l_a_c_e _t_h_e _u_n_i_x _d_a_t_e _p_r_o_g_r_a_m _w_i_t_h _o_n_e _w_r_i_t_t_e_n _i_n _l_i_s_p.
602:
603: % cat lispdate.l
604: (defun mydate nil
605: (patom "The date is ")
606: (patom (status ctime))
607: (terpr)
608: (exit 0))
609: (setq user-top-level 'mydate)
610:
611: % liszt -r lispdate
612: Compilation begins with Lisp Compiler 5.2
613: source: lispdate.l, result: lispdate.o
614: mydate
615: %Note: lispdate.l: Compilation complete
616: %Note: lispdate.l: Time: Real: 0:3, CPU: 0:0.28, GC: 0:0.00 for 0 gcs
617: %Note: lispdate.l: Assembly begins
618: %Note: lispdate.l: Assembly completed successfully
619: 3.0u 2.0s 0:17 29%
620:
621: _W_e _c_h_a_n_g_e _t_h_e _n_a_m_e _t_o _r_e_m_o_v_e _t_h_e "._o", (_t_h_i_s _i_s_n'_t _n_e_c_e_s_s_a_r_y)
622: % mv lispdate.o lispdate
623:
624: _N_o_w _w_e _t_e_s_t _i_t _o_u_t
625: % lispdate
626: The date is Sat Aug 1 16:58:33 1981
627: %
628: ____________________________________________________
629:
630:
631:
632:
633:
634:
635: 12.7. pure literals
636:
637: Normally the quoted lisp objects (literals) which
638: appear in functions are treated as constants. Consider
639: this function:
640:
641: (_d_e_f _f_o_o
642: (_l_a_m_b_d_a _n_i_l (_c_o_n_d ((_n_o_t (_e_q '_a (_c_a_r (_s_e_t_q _x '(_a
643: _b)))))
644: (_p_r_i_n_t '_i_m_p_o_s_s_i_b_l_e!!))
645: (_t (_r_p_l_a_c_a _x '_d)))))
646:
647: At first glance it seems that the first cond clause
648: will never be true, since the _c_a_r of (_a _b) should
649: always be _a. However if you run this function twice,
650: it will print 'impossible!!' the second time. This is
651:
652:
653: Printed: August 5, 1983
654:
655:
656:
657:
658:
659:
660:
661: Liszt - the lisp compiler 12-11
662:
663:
664: because the following clause modifies the 'constant'
665: list (_a _b) with the _r_p_l_a_c_a function. Such modifica-
666: tion of literal lisp objects can cause programs to
667: behave strangely as the above example shows, but more
668: importantly it can cause garbage collection problems
669: if done to compiled code. When a file is _f_a_s_led in,
670: if the symbol $purcopylits is non nil, the literal
671: lisp data is put in 'pure' space, that is it put in
672: space which needn't be looked at by the garabage col-
673: lector. This reduces the work the garbage collector
674: must do but it is dangerous since if the literals are
675: modified to point to non pure objects, the marker may
676: not mark the non pure objects. If the symbol $pur-
677: copylits is nil then the literal lisp data is put in
678: impure space and the compiled code will act like the
679: interpreted code when literal data is modified. The
680: default value for $purcopylits is t.
681:
682:
683:
684: 12.8. transfer tables
685:
686: A transfer table is setup by _f_a_s_l when the object
687: file is loaded in. There is one entry in the transfer
688: table for each function which is called in that object
689: file. The entry for a call to the function _f_o_o has
690: two parts whose contents are:
691:
692: [1] function address - This will initially point to
693: the internal function _q_l_i_n_k_e_r. It may some time
694: in the future point to the function _f_o_o if cer-
695: tain conditions are satisfied (more on this
696: below).
697:
698: [2] function name - This is a pointer to the symbol
699: _f_o_o. This will be used by _q_l_i_n_k_e_r.
700:
701:
702:
703: When a call is made to the function _f_o_o the call will
704: actually be made to the address in the transfer table
705: entry and will end up in the _q_l_i_n_k_e_r function.
706: _Q_l_i_n_k_e_r will determine that _f_o_o was the function being
707: called by locating the function name entry in the
708: transfer table[]. If the function being called is not
709: compiled then _q_l_i_n_k_e_r just calls _f_u_n_c_a_l_l to perform
710: ____________________
711: 9 []_Q_l_i_n_k_e_r does this by tracing back the call stack until
712: it finds the _c_a_l_l_s machine instruction which called it. The
713: address field of the _c_a_l_l_s contains the address of the
714: transfer table entry.
715:
716:
717:
718: 9 Printed: August 5, 1983
719:
720:
721:
722:
723:
724:
725:
726: Liszt - the lisp compiler 12-12
727:
728:
729: the function call. If _f_o_o is compiled and if
730: (_s_t_a_t_u_s _t_r_a_n_s_l_i_n_k) is non nil, then _q_l_i_n_k_e_r will
731: modify the function address part of the transfer table
732: to point directly to the function _f_o_o. Finally
733: _q_l_i_n_k_e_r will call _f_o_o directly . The next time a call
734: is made to _f_o_o the call will go directly to _f_o_o and
735: not through _q_l_i_n_k_e_r. This will result in a substan-
736: tial speedup in compiled code to compiled code
737: transfers. A disadvantage is that no debugging infor-
738: mation is left on the stack, so _s_h_o_w_s_t_a_c_k and _b_a_k_t_r_a_c_e
739: are useless. Another disadvantage is that if you
740: redefine a compiled function either through loading in
741: a new version or interactively defining it, then the
742: old version may still be called from compiled code if
743: the fast linking described above has already been
744: done. The solution to these problems is to use
745: (_s_s_t_a_t_u_s _t_r_a_n_s_l_i_n_k _v_a_l_u_e). If value is
746:
747: _n_i_l All transfer tables will be cleared, i.e. all
748: function addresses will be set to point to
749: _q_l_i_n_k_e_r. This means that the next time a func-
750: tion is called _q_l_i_n_k_e_r will be called and will
751: look at the current definition. Also, no fast
752: links will be set up since (_s_t_a_t_u_s _t_r_a_n_s_l_i_n_k)
753: will be nil. The end result is that _s_h_o_w_s_t_a_c_k
754: and _b_a_k_t_r_a_c_e will work and the function defini-
755: tion at the time of call will always be used.
756:
757: _o_n This causes the lisp system to go through all
758: transfer tables and set up fast links wherever
759: possible. This is normally used after you have
760: _f_a_s_led in all of your files. Furthermore since
761: (_s_t_a_t_u_s _t_r_a_n_s_l_i_n_k) is not nil, _q_l_i_n_k_e_r will make
762: new fast links if the situation arises (which
763: isn't likely unless you _f_a_s_l in another file).
764:
765: _t This or any other value not previously mentioned
766: will just make (_s_t_a_t_u_s _t_r_a_n_s_l_i_n_k) be non nil, and
767: as a result fast links will be made by _q_l_i_n_k_e_r
768: if the called function is compiled.
769:
770:
771:
772: 12.9. Fixnum functions
773:
774: The compiler will generate inline arithmetic code
775: for fixnum only functions. Such functions include +,
776: -, *, /, \, 1+ and 1-. The code generated will be
777: much faster than using _a_d_d, _d_i_f_f_e_r_e_n_c_e, etc. However
778: it will only work if the arguments to and results of
779: the functions are fixnums. No type checking is done.
780:
781: 9
782:
783: 9 Printed: August 5, 1983
784:
785:
786:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.