| blob | 4a20240a14921d690f0f6b708a17bf3215d2f419 |
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 ;;; Indexes PV-TABLES by indivisual slot names used.
61 ;;; ...and one lock to rule them. Spinlock because for certain (rare)
62 ;;; cases this lock might be grabbed in the course of method dispatch
63 ;;; -- and mostly this is already under the *big-compiler-lock*.
88 pv-table)))))
94 \f
117 nil)
118 elements)))))
123 pv)))
131 :value t
135 value
138 ;; This is safe: if another thread races us here the loser just
139 ;; misses the next time as well.
142 pv)))))
169 nil)))
170 slot-names))
174 slot-name
193 cwrapper pv-size pv-map))
194 cache))))))
213 \f
225 required-parameters))))
228 parameter-or-nil
229 env)))
241 slot-name
242 new-value))))))))))
244 ;;; Check whether the binding of the named variable is modified in the
245 ;;; method body.
256 slot-name nil)))
257 ;; We don't return the optimized form directly, since there's
258 ;; still a chance that we'll find out later on that the
259 ;; optimization should not have been done, for example due to
260 ;; the walker encountering a SETQ on SPARAMETER later on in
261 ;; the body [ see for example clos.impure.lisp test with :name
262 ;; ((:setq :method-parameter) slot-value)) ]. Instead we defer
263 ;; the decision until the compiler macroexpands
264 ;; OPTIMIZED-SLOT-VALUE.
265 ;;
266 ;; Note that we must still call OPTIMIZE-INSTANCE-ACCESS at
267 ;; this point (instead of when expanding
268 ;; OPTIMIZED-SLOT-VALUE), since it mutates the structure of
269 ;; SLOTS. If that mutation isn't done during the walking,
270 ;; MAKE-METHOD-LAMBDA-INTERNAL won't wrap a correct PV-BINDING
271 ;; form around the body, and compilation will fail. -- JES,
272 ;; 2006-09-18
278 ;; Either use OPTIMIZED-FORM or fall back to the safe
279 ;; ACCESSOR-SLOT-VALUE.
282 optimized-form))
290 slot-name new-value)))
291 ;; See OPTIMIZE-SLOT-VALUE
298 ;; Don't optimize slot value setting in safe code, since the
299 ;; optimized version will fail to catch some type errors
300 ;; (for example when a subclass declares a tighter type for
301 ;; the slot than a superclass).
306 optimized-form)))
314 slot-name nil)))
315 ;; See OPTIMIZE-SLOT-VALUE
323 optimized-form))
325 ;;; The SLOTS argument is an alist, the CAR of each entry is the name
326 ;;; of a required parameter to the function. The alist is in order, so
327 ;;; the position of an entry in the alist corresponds to the
328 ;;; argument's position in the lambda list.
330 read/write
331 sparameter
332 slot-name
333 new-value)
341 (:read
343 (:write
347 (:boundp
348 t)))
360 (:read
363 (:write
367 (:boundp
376 ;;; It is safe for these two functions to be wrong. They just try to
377 ;;; guess what the most likely case will be.
395 ;; FIXME: Is this really right? "Don't skip if there is
396 ;; no slot definition."
405 default
411 ;; FIXME: the line marked by KLUDGE below
412 ;; (and the analogous spot in
413 ;; INSTANCE-WRITE-INTERNAL) is there purely
414 ;; to suppress a type mismatch warning that
415 ;; propagates through to user code.
416 ;; Presumably SLOTS at this point can never
417 ;; actually be NIL, but the compiler seems
418 ;; to think it could, so we put this here
419 ;; to shut it up. (see also mail Rudi
420 ;; Schlatte sbcl-devel 2003-09-21) -- CSR,
421 ;; 2003-11-30
430 ,default
446 default
460 parameter
461 position
462 slot-name
463 class
464 new-value)
478 default
499 ;;; This magic function has quite a job to do indeed.
500 ;;;
501 ;;; The careful reader will recall that <slots> contains all of the
502 ;;; optimized slot access forms produced by OPTIMIZE-INSTANCE-ACCESS.
503 ;;; Each of these is a call to either INSTANCE-READ or INSTANCE-WRITE.
504 ;;;
505 ;;; At the time these calls were produced, the first argument was
506 ;;; specified as the symbol .PV-OFFSET.; what we have to do now is
507 ;;; convert those pv-offset arguments into the actual number that is
508 ;;; the correct offset into the pv.
509 ;;;
510 ;;; But first, oh but first, we sort <slots> a bit so that for each
511 ;;; argument we have the slots in alphabetical order. This
512 ;;; canonicalizes the PV-TABLE's a bit and will hopefully lead to
513 ;;; having fewer PV's floating around. Even if the gain is only
514 ;;; modest, it costs nothing.
520 slots)))
524 slot-name-lists))))
534 sorted-slots))
540 ;;; FIXME: Because of the existence of UNINTERN and RENAME-PACKAGE,
541 ;;; the part of this ordering which is based on SYMBOL-PKG-NAME is not
542 ;;; stable. This ordering is only used in to
543 ;;; SLOT-NAME-LISTS-FROM-SLOTS, where it serves to "canonicalize the
544 ;;; PV-TABLE's a bit and will hopefully lead to having fewer PV's
545 ;;; floating around", so it sounds as though the instability won't
546 ;;; actually lead to bugs, just small inefficiency. But still, it
547 ;;; would be better to reimplement this function as a comparison based
548 ;;; on SYMBOL-HASH:
549 ;;; * stable comparison
550 ;;; * smaller code (here, and in being able to discard SYMBOL-PKG-NAME)
551 ;;; * faster code.
575 #'symbol-or-cons-lessp
577 slots))
579 \f
580 ;;;; This needs to work in terms of metatypes and also needs to work
581 ;;;; for automatically generated reader and writer functions.
582 ;;;; Automatically generated reader and writer functions use this
583 ;;;; stuff too.
589 for required-parameter in required-parameters
590 for i from 0
602 slot-vars pv-parameters))
606 ;;; This will only be visible in PV-ENV when the default MAKE-METHOD-LAMBDA is
607 ;;; overridden.
613 ;; Decide which expansion to use based on the state of the PV-ENV-ENVIRONMENT
614 ;; symbol-macrolet.
623 ;; FIXME: VALUES was in this list, conditionalized with #+CMU, but I
624 ;; don't *think* CMU CL had, or SBCL has, VALUES declarations. If
625 ;; SBCL doesn't have 'em, VALUES should probably be removed from
626 ;; this list.
628 %method-name
629 %method-lambda-list
630 optimize
631 ftype
632 muffle-conditions
633 inline
634 notinline))
637 '(%class
638 type))
642 ignorable special dynamic-extent
643 ;; FIXME: Possibly this entire list and variable could go away.
644 ;; If not, certainly we should remove all these built-in typenames
645 ;; from the list, and replace them with a test for "is it a type
646 ;; name?" (CLTL1 allowed only built-in type names as declarations,
647 ;; but ANSI CL allows any type name as a declaration.)
648 array atom base-char bignum bit bit-vector character compiled-function
649 complex cons double-float extended-char
650 fixnum float function hash-table integer
651 keyword list long-float nil null number package pathname random-state ratio
652 rational readtable sequence short-float signed-byte simple-array
653 simple-bit-vector simple-string simple-vector single-float standard-char
654 stream string symbol t unsigned-byte vector))
659 decl)
679 ;; FIXME: This warning, and perhaps the
680 ;; various *VAR-DECLARATIONS-FOO* and/or
681 ;; *NON-VAR-DECLARATIONS* variables,
682 ;; could probably go away now that we're not
683 ;; trying to be portable between different
684 ;; CLTL1 hosts the way PCL was. (Note that to
685 ;; do this right, we need to be able to handle
686 ;; user-defined (DECLAIM (DECLARATION FOO))
687 ;; stuff.)
689 Please put ~S on one of the lists ~S,~%~S, or~%~S.~@
690 (Assuming it is a variable declaration without argument)."
691 declaration-name 'split-declarations
692 declaration-name
704 ;; Quietly remove IGNORE declarations
705 ;; on args when a next-method is
706 ;; involved, to prevent compiler
707 ;; warnings about ignored args being
708 ;; read.
718 inner-decls)))))))))
722 ;;; Pull a name out of the %METHOD-NAME declaration in the function
723 ;;; body given, or return NIL if no %METHOD-NAME declaration is found.
731 name)))))
733 ;;; Convert a lambda expression containing a SB-PCL::%METHOD-NAME
734 ;;; declaration (which is a naming style internal to PCL) into an
735 ;;; SB-INT:NAMED-LAMBDA expression (which is a naming style used
736 ;;; throughout SBCL, understood by the main compiler); or if there's
737 ;;; no SB-PCL::%METHOD-NAME declaration, then just return the original
738 ;;; lambda expression.
743 method-lambda)))
748 lmf ; becomes body of function
749 lmf-params)
778 ;; Given a valid lambda list, extract the parameter names.
780 with res = nil
785 ;; ... ((:BAR FOO) 1)
787 ;; ... (FOO 1)
789 ;; ... (... 1 FOO-P)
793 ;; ... FOO
801 ;; Names of the parameters that will be in the outermost lambda-list
802 ;; (and whose bound declarations thus need to be in OUTER-DECLS).
804 ;; The lambda-list used by BIND-ARGS
809 ;; Try to use the normal function call machinery instead of BIND-ARGS
810 ;; binding the arguments, unless:
812 ;; in any case.
814 ;; CALL-NEXT-METHOD wants to use BIND-ARGS, and needs a
815 ;; list of all non-required arguments.
816 call-next-method-p)
818 restp nil
819 ;; Get all the parameters for declaration parsing
821 ;; Ensure that BIND-ARGS won't do anything (since
822 ;; BIND-LIST won't contain any non-required parameters,
823 ;; and REQ-ARGS will be of an equal length). We still want
824 ;; to pass BIND-LIST to FAST-LEXICAL-METHOD-FUNCTIONS so
825 ;; that BIND-FAST-LEXICAL-METHOD-FUNCTIONS can take care
826 ;; of rebinding SETQd required arguments around the method
827 ;; body.
828 bind-list req-args))
837 req-args
838 lambda-list))))
840 :function
843 ;; function name
845 ;; The lambda-list of the FMF
847 ;; body of the function
850 ,@outer-decls
855 ,@inner-decls
860 mf)
863 ;;; Use arrays and hash tables and the fngen stuff to make this much
864 ;;; better. It doesn't really matter, though, because a function
865 ;;; returned by this will get called only when the user explicitly
866 ;;; funcalls a result of method-function. BUT, this is needed to make
867 ;;; early methods work.
887 nm)
890 ;; FIXME: this looks dangerous.
894 method-function))
896 ;;; this is similar to the above, only not quite. Only called when
897 ;;; the MOP is heavily involved. Not quite parallel to
898 ;;; METHOD-FUNCTION-FROM-FAST-METHOD-FUNCTION, because we can close
899 ;;; over the actual PV-CELL in this case.
913 nm)
931 when snl
934 ;;; Return the subset of WRAPPERS which is used in the cache
935 ;;; of PV-TABLE.
938 when snl
939 collect w))