| blob | 63299b90275945756e6934f6592443ecc358fd74 |
1 ;;;; permutation vectors
3 ;;;; This software is part of the SBCL system. See the README file for
4 ;;;; more information.
6 ;;;; This software is derived from software originally released by Xerox
7 ;;;; Corporation. Copyright and release statements follow. Later modifications
8 ;;;; to the software are in the public domain and are provided with
9 ;;;; absolutely no warranty. See the COPYING and CREDITS files for more
10 ;;;; information.
12 ;;;; copyright information from original PCL sources:
13 ;;;;
14 ;;;; Copyright (c) 1985, 1986, 1987, 1988, 1989, 1990 Xerox Corporation.
15 ;;;; All rights reserved.
16 ;;;;
17 ;;;; Use and copying of this software and preparation of derivative works based
18 ;;;; upon this software are permitted. Any distribution of this software or
19 ;;;; derivative works must comply with all applicable United States export
20 ;;;; control laws.
21 ;;;;
22 ;;;; This software is made available AS IS, and Xerox Corporation makes no
23 ;;;; warranty about the software, its performance or its conformity to any
24 ;;;; specification.
28 ;;;; Up to 1.0.9.24 SBCL used to have a sketched out implementation
29 ;;;; for optimizing GF calls inside method bodies using a PV approach,
30 ;;;; inherited from the original PCL. This was never completed, and
31 ;;;; was removed at that point to make the code easier to understand
32 ;;;; -- but:
33 ;;;;
34 ;;;; FIXME: It would be possible to optimize GF calls inside method
35 ;;;; bodies using permutation vectors: if all the arguments to the
36 ;;;; GF are specializers parameters, we can assign a permutation index
37 ;;;; to each such (GF . ARGS) tuple inside a method body, and use this
38 ;;;; to cache effective method functions.
39 \f
50 ;;; Used for interning parts of SLOT-NAME-LISTS, as part of
51 ;;; PV-TABLE interning -- just to save space.
54 ;;; Used for interning PV-TABLES, keyed by the SLOT-NAME-LISTS
55 ;;; used.
58 ;;; ...and one lock to rule them. Spinlock because for certain (rare)
59 ;;; cases this lock might be grabbed in the course of method dispatch
60 ;;; -- and mostly this is already under the *big-compiler-lock*.
66 ;; FIXME: NIL at the head of the list is a remnant from
67 ;; old purged code, that hasn't been quite cleaned up yet.
68 ;; ...but as long as we assume it is there, we may as well
69 ;; assert it.
82 \f
105 nil)
106 elements)))))
111 pv)))
119 :value t
123 value
126 ;; This is safe: if another thread races us here the loser just
127 ;; misses the next time as well.
130 pv)))))
134 \f
146 required-parameters))))
149 parameter-or-nil
150 env)))
162 slot-name
163 new-value))))))))))
165 ;;; Check whether the binding of the named variable is modified in the
166 ;;; method body.
177 slot-name nil)))
178 ;; We don't return the optimized form directly, since there's
179 ;; still a chance that we'll find out later on that the
180 ;; optimization should not have been done, for example due to
181 ;; the walker encountering a SETQ on SPARAMETER later on in
182 ;; the body [ see for example clos.impure.lisp test with :name
183 ;; ((:setq :method-parameter) slot-value)) ]. Instead we defer
184 ;; the decision until the compiler macroexpands
185 ;; OPTIMIZED-SLOT-VALUE.
186 ;;
187 ;; Note that we must still call OPTIMIZE-INSTANCE-ACCESS at
188 ;; this point (instead of when expanding
189 ;; OPTIMIZED-SLOT-VALUE), since it mutates the structure of
190 ;; SLOTS. If that mutation isn't done during the walking,
191 ;; MAKE-METHOD-LAMBDA-INTERNAL won't wrap a correct PV-BINDING
192 ;; form around the body, and compilation will fail. -- JES,
193 ;; 2006-09-18
199 ;; Either use OPTIMIZED-FORM or fall back to the safe
200 ;; ACCESSOR-SLOT-VALUE.
203 optimized-form))
211 slot-name new-value)))
212 ;; See OPTIMIZE-SLOT-VALUE
219 ;; Don't optimize slot value setting in safe code, since the
220 ;; optimized version will fail to catch some type errors
221 ;; (for example when a subclass declares a tighter type for
222 ;; the slot than a superclass).
227 optimized-form)))
235 slot-name nil)))
236 ;; See OPTIMIZE-SLOT-VALUE
244 optimized-form))
246 ;;; The SLOTS argument is an alist, the CAR of each entry is the name
247 ;;; of a required parameter to the function. The alist is in order, so
248 ;;; the position of an entry in the alist corresponds to the
249 ;;; argument's position in the lambda list.
251 read/write
252 sparameter
253 slot-name
254 new-value)
262 (:read
264 (:write
268 (:boundp
269 t)))
281 (:read
284 (:write
288 (:boundp
297 ;;; It is safe for these two functions to be wrong. They just try to
298 ;;; guess what the most likely case will be.
316 ;; FIXME: Is this really right? "Don't skip if there is
317 ;; no slot definition."
326 default
332 ;; FIXME: the line marked by KLUDGE below
333 ;; (and the analogous spot in
334 ;; INSTANCE-WRITE-INTERNAL) is there purely
335 ;; to suppress a type mismatch warning that
336 ;; propagates through to user code.
337 ;; Presumably SLOTS at this point can never
338 ;; actually be NIL, but the compiler seems
339 ;; to think it could, so we put this here
340 ;; to shut it up. (see also mail Rudi
341 ;; Schlatte sbcl-devel 2003-09-21) -- CSR,
342 ;; 2003-11-30
351 ,default
367 default
381 parameter
382 position
383 slot-name
384 class
385 new-value)
399 default
420 ;;; This magic function has quite a job to do indeed.
421 ;;;
422 ;;; The careful reader will recall that <slots> contains all of the
423 ;;; optimized slot access forms produced by OPTIMIZE-INSTANCE-ACCESS.
424 ;;; Each of these is a call to either INSTANCE-READ or INSTANCE-WRITE.
425 ;;;
426 ;;; At the time these calls were produced, the first argument was
427 ;;; specified as the symbol .PV-OFFSET.; what we have to do now is
428 ;;; convert those pv-offset arguments into the actual number that is
429 ;;; the correct offset into the pv.
430 ;;;
431 ;;; But first, oh but first, we sort <slots> a bit so that for each
432 ;;; argument we have the slots in alphabetical order. This
433 ;;; canonicalizes the PV-TABLE's a bit and will hopefully lead to
434 ;;; having fewer PV's floating around. Even if the gain is only
435 ;;; modest, it costs nothing.
441 slots)))
445 slot-name-lists))))
455 sorted-slots))
461 ;;; FIXME: Because of the existence of UNINTERN and RENAME-PACKAGE,
462 ;;; the part of this ordering which is based on SYMBOL-PKG-NAME is not
463 ;;; stable. This ordering is only used in to
464 ;;; SLOT-NAME-LISTS-FROM-SLOTS, where it serves to "canonicalize the
465 ;;; PV-TABLE's a bit and will hopefully lead to having fewer PV's
466 ;;; floating around", so it sounds as though the instability won't
467 ;;; actually lead to bugs, just small inefficiency. But still, it
468 ;;; would be better to reimplement this function as a comparison based
469 ;;; on SYMBOL-HASH:
470 ;;; * stable comparison
471 ;;; * smaller code (here, and in being able to discard SYMBOL-PKG-NAME)
472 ;;; * faster code.
496 #'symbol-or-cons-lessp
498 slots))
500 \f
501 ;;;; This needs to work in terms of metatypes and also needs to work
502 ;;;; for automatically generated reader and writer functions.
503 ;;;; Automatically generated reader and writer functions use this
504 ;;;; stuff too.
510 for required-parameter in required-parameters
511 for i from 0
523 slot-vars pv-parameters))
527 ;;; This will only be visible in PV-ENV when the default MAKE-METHOD-LAMBDA is
528 ;;; overridden.
534 ;; Decide which expansion to use based on the state of the PV-ENV-ENVIRONMENT
535 ;; symbol-macrolet.
544 ;; FIXME: VALUES was in this list, conditionalized with #+CMU, but I
545 ;; don't *think* CMU CL had, or SBCL has, VALUES declarations. If
546 ;; SBCL doesn't have 'em, VALUES should probably be removed from
547 ;; this list.
549 %method-name
550 %method-lambda-list
551 optimize
552 ftype
553 muffle-conditions
554 inline
555 notinline))
558 '(%class
559 type))
563 ignorable special dynamic-extent
564 ;; FIXME: Possibly this entire list and variable could go away.
565 ;; If not, certainly we should remove all these built-in typenames
566 ;; from the list, and replace them with a test for "is it a type
567 ;; name?" (CLTL1 allowed only built-in type names as declarations,
568 ;; but ANSI CL allows any type name as a declaration.)
569 array atom base-char bignum bit bit-vector character compiled-function
570 complex cons double-float extended-char
571 fixnum float function hash-table integer
572 keyword list long-float nil null number package pathname random-state ratio
573 rational readtable sequence short-float signed-byte simple-array
574 simple-bit-vector simple-string simple-vector single-float standard-char
575 stream string symbol t unsigned-byte vector))
580 decl)
600 ;; FIXME: This warning, and perhaps the
601 ;; various *VAR-DECLARATIONS-FOO* and/or
602 ;; *NON-VAR-DECLARATIONS* variables,
603 ;; could probably go away now that we're not
604 ;; trying to be portable between different
605 ;; CLTL1 hosts the way PCL was. (Note that to
606 ;; do this right, we need to be able to handle
607 ;; user-defined (DECLAIM (DECLARATION FOO))
608 ;; stuff.)
610 Please put ~S on one of the lists ~S,~%~S, or~%~S.~@
611 (Assuming it is a variable declaration without argument)."
612 declaration-name 'split-declarations
613 declaration-name
625 ;; Quietly remove IGNORE declarations
626 ;; on args when a next-method is
627 ;; involved, to prevent compiler
628 ;; warnings about ignored args being
629 ;; read.
639 inner-decls)))))))))
643 ;;; Pull a name out of the %METHOD-NAME declaration in the function
644 ;;; body given, or return NIL if no %METHOD-NAME declaration is found.
652 name)))))
654 ;;; Convert a lambda expression containing a SB-PCL::%METHOD-NAME
655 ;;; declaration (which is a naming style internal to PCL) into an
656 ;;; SB-INT:NAMED-LAMBDA expression (which is a naming style used
657 ;;; throughout SBCL, understood by the main compiler); or if there's
658 ;;; no SB-PCL::%METHOD-NAME declaration, then just return the original
659 ;;; lambda expression.
664 method-lambda)))
669 lmf ; becomes body of function
670 lmf-params)
699 ;; Given a valid lambda list, extract the parameter names.
701 with res = nil
706 ;; ... ((:BAR FOO) 1)
708 ;; ... (FOO 1)
710 ;; ... (... 1 FOO-P)
714 ;; ... FOO
722 ;; Names of the parameters that will be in the outermost lambda-list
723 ;; (and whose bound declarations thus need to be in OUTER-DECLS).
725 ;; The lambda-list used by BIND-ARGS
730 ;; Try to use the normal function call machinery instead of BIND-ARGS
731 ;; binding the arguments, unless:
733 ;; in any case.
735 ;; CALL-NEXT-METHOD wants to use BIND-ARGS, and needs a
736 ;; list of all non-required arguments.
737 call-next-method-p)
739 restp nil
740 ;; Get all the parameters for declaration parsing
742 ;; Ensure that BIND-ARGS won't do anything (since
743 ;; BIND-LIST won't contain any non-required parameters,
744 ;; and REQ-ARGS will be of an equal length). We still want
745 ;; to pass BIND-LIST to FAST-LEXICAL-METHOD-FUNCTIONS so
746 ;; that BIND-FAST-LEXICAL-METHOD-FUNCTIONS can take care
747 ;; of rebinding SETQd required arguments around the method
748 ;; body.
749 bind-list req-args))
758 req-args
759 lambda-list))))
761 :function
764 ;; function name
766 ;; The lambda-list of the FMF
768 ;; body of the function
771 ,@outer-decls
776 ,@inner-decls
781 mf)
784 ;;; Use arrays and hash tables and the fngen stuff to make this much
785 ;;; better. It doesn't really matter, though, because a function
786 ;;; returned by this will get called only when the user explicitly
787 ;;; funcalls a result of method-function. BUT, this is needed to make
788 ;;; early methods work.
808 nm)
811 ;; FIXME: this looks dangerous.
815 method-function))
817 ;;; this is similar to the above, only not quite. Only called when
818 ;;; the MOP is heavily involved. Not quite parallel to
819 ;;; METHOD-FUNCTION-FROM-FAST-METHOD-FUNCTION, because we can close
820 ;;; over the actual PV-CELL in this case.
834 nm)
852 and arg in args
853 when snl
856 ;;; Return the subset of WRAPPERS which is used in the cache
857 ;;; of PV-TABLE.
860 when snl
861 collect w))