| blob | 9aef26daaac3af87d6f4ecd142a7855b286861ec |
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
47 \f
58 ;;; Used for interning parts of SLOT-NAME-LISTS, as part of
59 ;;; PV-TABLE interning -- just to save space.
62 ;;; Used for interning PV-TABLES, keyed by the SLOT-NAME-LISTS
63 ;;; used.
66 ;;; Indexes PV-TABLES by indivisual slot names used.
69 ;;; ...and one lock to rule them. Spinlock because for certain (rare)
70 ;;; cases this lock might be grabbed in the course of method dispatch
71 ;;; -- and mostly this is already under the *big-compiler-lock*.
96 pv-table)))))
102 \f
137 nil)
138 elements)))))
143 pv)))
151 :value t
155 value
158 ;; This is safe: if another thread races us here the loser just
159 ;; misses the next time as well.
162 pv)))))
190 nil)))
191 slot-names))
195 slot-name
214 cwrapper pv-size pv-map))
215 cache))))))
234 \f
246 required-parameters))))
249 parameter-or-nil
250 env)))
262 slot-name
263 new-value))))))))))
265 ;;; Check whether the binding of the named variable is modified in the
266 ;;; method body.
277 slot-name nil)))
278 ;; We don't return the optimized form directly, since there's
279 ;; still a chance that we'll find out later on that the
280 ;; optimization should not have been done, for example due to
281 ;; the walker encountering a SETQ on SPARAMETER later on in
282 ;; the body [ see for example clos.impure.lisp test with :name
283 ;; ((:setq :method-parameter) slot-value)) ]. Instead we defer
284 ;; the decision until the compiler macroexpands
285 ;; OPTIMIZED-SLOT-VALUE.
286 ;;
287 ;; Note that we must still call OPTIMIZE-INSTANCE-ACCESS at
288 ;; this point (instead of when expanding
289 ;; OPTIMIZED-SLOT-VALUE), since it mutates the structure of
290 ;; SLOTS. If that mutation isn't done during the walking,
291 ;; MAKE-METHOD-LAMBDA-INTERNAL won't wrap a correct PV-BINDING
292 ;; form around the body, and compilation will fail. -- JES,
293 ;; 2006-09-18
299 ;; Either use OPTIMIZED-FORM or fall back to the safe
300 ;; ACCESSOR-SLOT-VALUE.
303 optimized-form))
311 slot-name new-value)))
312 ;; See OPTIMIZE-SLOT-VALUE
319 ;; Don't optimize slot value setting in safe code, since the
320 ;; optimized version will fail to catch some type errors
321 ;; (for example when a subclass declares a tighter type for
322 ;; the slot than a superclass).
327 optimized-form)))
335 slot-name nil)))
336 ;; See OPTIMIZE-SLOT-VALUE
344 optimized-form))
346 ;;; The SLOTS argument is an alist, the CAR of each entry is the name
347 ;;; of a required parameter to the function. The alist is in order, so
348 ;;; the position of an entry in the alist corresponds to the
349 ;;; argument's position in the lambda list.
351 read/write
352 sparameter
353 slot-name
354 new-value)
362 (:read
364 (:write
368 (:boundp
369 t)))
381 (:read
384 (:write
388 (:boundp
397 ;;; It is safe for these two functions to be wrong. They just try to
398 ;;; guess what the most likely case will be.
416 ;; FIXME: Is this really right? "Don't skip if there is
417 ;; no slot definition."
426 default
432 ;; FIXME: the line marked by KLUDGE below
433 ;; (and the analogous spot in
434 ;; INSTANCE-WRITE-INTERNAL) is there purely
435 ;; to suppress a type mismatch warning that
436 ;; propagates through to user code.
437 ;; Presumably SLOTS at this point can never
438 ;; actually be NIL, but the compiler seems
439 ;; to think it could, so we put this here
440 ;; to shut it up. (see also mail Rudi
441 ;; Schlatte sbcl-devel 2003-09-21) -- CSR,
442 ;; 2003-11-30
451 ,default
467 default
481 parameter
482 position
483 slot-name
484 class
485 new-value)
499 default
520 ;;; This magic function has quite a job to do indeed.
521 ;;;
522 ;;; The careful reader will recall that <slots> contains all of the
523 ;;; optimized slot access forms produced by OPTIMIZE-INSTANCE-ACCESS.
524 ;;; Each of these is a call to either INSTANCE-READ or INSTANCE-WRITE.
525 ;;;
526 ;;; At the time these calls were produced, the first argument was
527 ;;; specified as the symbol .PV-OFFSET.; what we have to do now is
528 ;;; convert those pv-offset arguments into the actual number that is
529 ;;; the correct offset into the pv.
530 ;;;
531 ;;; But first, oh but first, we sort <slots> a bit so that for each
532 ;;; argument we have the slots in alphabetical order. This
533 ;;; canonicalizes the PV-TABLE's a bit and will hopefully lead to
534 ;;; having fewer PV's floating around. Even if the gain is only
535 ;;; modest, it costs nothing.
541 slots)))
545 slot-name-lists))))
555 sorted-slots))
561 ;;; FIXME: Because of the existence of UNINTERN and RENAME-PACKAGE,
562 ;;; the part of this ordering which is based on SYMBOL-PKG-NAME is not
563 ;;; stable. This ordering is only used in to
564 ;;; SLOT-NAME-LISTS-FROM-SLOTS, where it serves to "canonicalize the
565 ;;; PV-TABLE's a bit and will hopefully lead to having fewer PV's
566 ;;; floating around", so it sounds as though the instability won't
567 ;;; actually lead to bugs, just small inefficiency. But still, it
568 ;;; would be better to reimplement this function as a comparison based
569 ;;; on SYMBOL-HASH:
570 ;;; * stable comparison
571 ;;; * smaller code (here, and in being able to discard SYMBOL-PKG-NAME)
572 ;;; * faster code.
596 #'symbol-or-cons-lessp
598 slots))
600 \f
601 ;;;; This needs to work in terms of metatypes and also needs to work
602 ;;;; for automatically generated reader and writer functions.
603 ;;;; Automatically generated reader and writer functions use this
604 ;;;; stuff too.
610 for required-parameter in required-parameters
611 for i from 0
623 slot-vars pv-parameters))
627 ;;; This will only be visible in PV-ENV when the default MAKE-METHOD-LAMBDA is
628 ;;; overridden.
634 ;; Decide which expansion to use based on the state of the PV-ENV-ENVIRONMENT
635 ;; symbol-macrolet.
644 ;; FIXME: VALUES was in this list, conditionalized with #+CMU, but I
645 ;; don't *think* CMU CL had, or SBCL has, VALUES declarations. If
646 ;; SBCL doesn't have 'em, VALUES should probably be removed from
647 ;; this list.
649 %method-name
650 %method-lambda-list
651 optimize
652 ftype
653 muffle-conditions
654 inline
655 notinline))
658 '(%class
659 type))
663 ignorable special dynamic-extent
664 ;; FIXME: Possibly this entire list and variable could go away.
665 ;; If not, certainly we should remove all these built-in typenames
666 ;; from the list, and replace them with a test for "is it a type
667 ;; name?" (CLTL1 allowed only built-in type names as declarations,
668 ;; but ANSI CL allows any type name as a declaration.)
669 array atom base-char bignum bit bit-vector character compiled-function
670 complex cons double-float extended-char
671 fixnum float function hash-table integer
672 keyword list long-float nil null number package pathname random-state ratio
673 rational readtable sequence short-float signed-byte simple-array
674 simple-bit-vector simple-string simple-vector single-float standard-char
675 stream string symbol t unsigned-byte vector))
680 decl)
700 ;; FIXME: This warning, and perhaps the
701 ;; various *VAR-DECLARATIONS-FOO* and/or
702 ;; *NON-VAR-DECLARATIONS* variables,
703 ;; could probably go away now that we're not
704 ;; trying to be portable between different
705 ;; CLTL1 hosts the way PCL was. (Note that to
706 ;; do this right, we need to be able to handle
707 ;; user-defined (DECLAIM (DECLARATION FOO))
708 ;; stuff.)
710 Please put ~S on one of the lists ~S,~%~S, or~%~S.~@
711 (Assuming it is a variable declaration without argument)."
712 declaration-name 'split-declarations
713 declaration-name
725 ;; Quietly remove IGNORE declarations
726 ;; on args when a next-method is
727 ;; involved, to prevent compiler
728 ;; warnings about ignored args being
729 ;; read.
739 inner-decls)))))))))
743 ;;; Pull a name out of the %METHOD-NAME declaration in the function
744 ;;; body given, or return NIL if no %METHOD-NAME declaration is found.
752 name)))))
754 ;;; Convert a lambda expression containing a SB-PCL::%METHOD-NAME
755 ;;; declaration (which is a naming style internal to PCL) into an
756 ;;; SB-INT:NAMED-LAMBDA expression (which is a naming style used
757 ;;; throughout SBCL, understood by the main compiler); or if there's
758 ;;; no SB-PCL::%METHOD-NAME declaration, then just return the original
759 ;;; lambda expression.
764 method-lambda)))
769 lmf ; becomes body of function
770 lmf-params)
799 ;; Given a valid lambda list, extract the parameter names.
801 with res = nil
806 ;; ... ((:BAR FOO) 1)
808 ;; ... (FOO 1)
810 ;; ... (... 1 FOO-P)
814 ;; ... FOO
822 ;; Names of the parameters that will be in the outermost lambda-list
823 ;; (and whose bound declarations thus need to be in OUTER-DECLS).
825 ;; The lambda-list used by BIND-ARGS
830 ;; Try to use the normal function call machinery instead of BIND-ARGS
831 ;; binding the arguments, unless:
833 ;; in any case.
835 ;; CALL-NEXT-METHOD wants to use BIND-ARGS, and needs a
836 ;; list of all non-required arguments.
837 call-next-method-p)
839 restp nil
840 ;; Get all the parameters for declaration parsing
842 ;; Ensure that BIND-ARGS won't do anything (since
843 ;; BIND-LIST won't contain any non-required parameters,
844 ;; and REQ-ARGS will be of an equal length). We still want
845 ;; to pass BIND-LIST to FAST-LEXICAL-METHOD-FUNCTIONS so
846 ;; that BIND-FAST-LEXICAL-METHOD-FUNCTIONS can take care
847 ;; of rebinding SETQd required arguments around the method
848 ;; body.
849 bind-list req-args))
858 req-args
859 lambda-list))))
861 :function
864 ;; function name
866 ;; The lambda-list of the FMF
868 ;; body of the function
871 ,@outer-decls
876 ,@inner-decls
881 mf)
884 ;;; Use arrays and hash tables and the fngen stuff to make this much
885 ;;; better. It doesn't really matter, though, because a function
886 ;;; returned by this will get called only when the user explicitly
887 ;;; funcalls a result of method-function. BUT, this is needed to make
888 ;;; early methods work.
908 nm)
911 ;; FIXME: this looks dangerous.
915 method-function))
917 ;;; this is similar to the above, only not quite. Only called when
918 ;;; the MOP is heavily involved. Not quite parallel to
919 ;;; METHOD-FUNCTION-FROM-FAST-METHOD-FUNCTION, because we can close
920 ;;; over the actual PV-CELL in this case.
934 nm)
952 wrapper)
953 wrappers)))))
957 when snl
961 ;;; Return the subset of WRAPPERS which is used in the cache
962 ;;; of PV-TABLE.
965 when snl
966 collect w into result