X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcompiler%2Feval-comp.lisp;h=39238fbb5b83495e909d1a06486c5e520b60482e;hb=a1a2c079c7654defb618baad0dddcf0eaf2ce64f;hp=e686677e5bd3c020498baceea720538215b6181d;hpb=a530bbe337109d898d5b4a001fc8f1afa3b5dc39;p=sbcl.git diff --git a/src/compiler/eval-comp.lisp b/src/compiler/eval-comp.lisp index e686677..39238fb 100644 --- a/src/compiler/eval-comp.lisp +++ b/src/compiler/eval-comp.lisp @@ -13,9 +13,6 @@ (in-package "SB!C") -(file-comment - "$Header$") - ;;; FIXME: Doesn't this belong somewhere else, like early-c.lisp? (declaim (special *constants* *free-variables* *component-being-compiled* *code-vector* *next-location* *result-fixups* @@ -38,7 +35,7 @@ ;;; Translate form into the compiler's IR1 and perform environment ;;; analysis. This is sort of a combination of COMPILE-FILE, ;;; SUB-COMPILE-FILE, COMPILE-TOP-LEVEL, and COMPILE-COMPONENT. -(defun compile-for-eval (form quietly) +(defun compile-for-eval (form) (with-ir1-namespace (let* ((*block-compile* nil) (*lexenv* (make-null-lexenv)) @@ -95,7 +92,8 @@ ;;;; annotating IR1 for interpretation (defstruct (lambda-eval-info (:constructor make-lambda-eval-info - (frame-size args-passed entries))) + (frame-size args-passed entries)) + (:copier nil)) frame-size ; number of stack locations needed to hold locals args-passed ; number of referenced arguments passed to lambda entries ; a-list mapping entry nodes to stack locations @@ -104,60 +102,66 @@ (print-unreadable-object (obj str :type t))) (defstruct (entry-node-info (:constructor make-entry-node-info - (st-top nlx-tag))) + (st-top nlx-tag)) + (:copier nil)) st-top ; stack top when we encounter the entry node nlx-tag) ; tag to which to throw to get back entry node's context (def!method print-object ((obj entry-node-info) str) (print-unreadable-object (obj str :type t))) -;;; Some compiler funny functions have definitions, so the interpreter can -;;; call them. These require special action to coordinate the interpreter, -;;; system call stack, and the environment. The annotation prepass marks the -;;; references to these as :unused, so the interpreter doesn't try to fetch -;;; functions through these undefined symbols. +;;; Some compiler funny functions have definitions, so the interpreter +;;; can call them. These require special action to coordinate the +;;; interpreter, system call stack, and the environment. The +;;; annotation prepass marks the references to these as :UNUSED, so +;;; the interpreter doesn't try to fetch functions through these +;;; undefined symbols. (defconstant undefined-funny-funs '(%special-bind %special-unbind %more-arg-context %unknown-values %catch %unwind-protect %catch-breakup %unwind-protect-breakup %lexical-exit-breakup %continue-unwind %nlx-entry)) -;;; Some kinds of functions are only passed as arguments to funny functions, -;;; and are never actually evaluated at run time. +;;; Some kinds of functions are only passed as arguments to funny +;;; functions, and are never actually evaluated at run time. (defconstant non-closed-function-kinds '(:cleanup :escape)) ;;; This annotates continuations, lambda-vars, and lambdas. For each -;;; continuation, we cache how its destination uses its value. This only buys -;;; efficiency when the code executes more than once, but the overhead of this -;;; part of the prepass for code executed only once should be negligible. +;;; continuation, we cache how its destination uses its value. This +;;; only buys efficiency when the code executes more than once, but +;;; the overhead of this part of the prepass for code executed only +;;; once should be negligible. ;;; -;;; As a special case to aid interpreting local function calls, we sometimes -;;; note the continuation as :unused. This occurs when there is a local call, -;;; and there is no actual function object to call; we mark the continuation as -;;; :unused since there is nothing to push on the interpreter's stack. -;;; Normally we would see a reference to a function that we would push on the -;;; stack to later pop and apply to the arguments on the stack. To determine -;;; when we have a local call with no real function object, we look at the node -;;; to see whether it is a reference with a destination that is a :local -;;; combination whose function is the reference node's continuation. +;;; As a special case to aid interpreting local function calls, we +;;; sometimes note the continuation as :unused. This occurs when there +;;; is a local call, and there is no actual function object to call; +;;; we mark the continuation as :unused since there is nothing to push +;;; on the interpreter's stack. Normally we would see a reference to a +;;; function that we would push on the stack to later pop and apply to +;;; the arguments on the stack. To determine when we have a local call +;;; with no real function object, we look at the node to see whether +;;; it is a reference with a destination that is a :local combination +;;; whose function is the reference node's continuation. ;;; -;;; After checking for virtual local calls, we check for funny functions the -;;; compiler refers to for calling to note certain operations. These functions -;;; are undefined, and if the interpreter tried to reference the function cells -;;; of these symbols, it would get an error. We mark the continuations -;;; delivering the values of these references as :unused, so the reference -;;; never takes place. +;;; After checking for virtual local calls, we check for funny +;;; functions the compiler refers to for calling to note certain +;;; operations. These functions are undefined, and if the interpreter +;;; tried to reference the function cells of these symbols, it would +;;; get an error. We mark the continuations delivering the values of +;;; these references as :unused, so the reference never takes place. ;;; -;;; For each lambda-var, including a lambda's vars and its let's vars, we note -;;; the stack offset used to access and store that variable. Then we note the -;;; lambda with the total number of variables, so we know how big its stack -;;; frame is. Also in the lambda's info is the number of its arguments that it -;;; actually references; the interpreter never pushes or pops an unreferenced -;;; argument, so we can't just use LENGTH on LAMBDA-VARS to know how many args -;;; the caller passed. +;;; For each lambda-var, including a LAMBDA's vars and its LET's vars, +;;; we note the stack offset used to access and store that variable. +;;; Then we note the lambda with the total number of variables, so we +;;; know how big its stack frame is. Also in the lambda's info is the +;;; number of its arguments that it actually references; the +;;; interpreter never pushes or pops an unreferenced argument, so we +;;; can't just use LENGTH on LAMBDA-VARS to know how many args the +;;; caller passed. ;;; -;;; For each entry node in a lambda, we associate in the lambda-eval-info the -;;; entry node with a stack offset. Evaluation code stores the frame pointer -;;; in this slot upon processing the entry node to aid stack cleanup and -;;; correct frame manipulation when processing exit nodes. +;;; For each entry node in a lambda, we associate in the +;;; lambda-eval-info the entry node with a stack offset. Evaluation +;;; code stores the frame pointer in this slot upon processing the +;;; entry node to aid stack cleanup and correct frame manipulation +;;; when processing exit nodes. (defun annotate-component-for-eval (component) (do-blocks (b component) (do-nodes (node cont b) @@ -178,12 +182,12 @@ ((and leaf (typep leaf 'clambda) (member (functional-kind leaf) non-closed-function-kinds)) - (assert (not (eq (functional-kind leaf) :escape))) + (aver (not (eq (functional-kind leaf) :escape))) :unused) (t (typecase dest - ;; Change locations in eval.lisp that think :RETURN - ;; could occur. + ;; Change locations in eval.lisp that think + ;; :RETURN could occur. ((or mv-combination creturn exit) :multiple) (null :unused) (t :single)))))))) @@ -229,14 +233,14 @@ ((:catch :unwind-protect) (return :blow-it-off)))))))) -;;; Sometime consider annotations to exclude processing of exit nodes when -;;; we want to do a tail-p thing. +;;; Sometime consider annotations to exclude processing of exit nodes +;;; when we want to do a tail-p thing. ;;;; defining funny functions for interpreter #| %listify-rest-args %more-arg %verify-argument-count %argument-count-error -%odd-keyword-arguments-error %unknown-keyword-argument-error +%odd-key-arguments-error %unknown-key-argument-error |# (defun %verify-argument-count (supplied-args defined-args) @@ -267,15 +271,15 @@ :format-control "wrong number of arguments passed: ~S" :format-arguments (list args-passed-count))) -(defun %odd-keyword-arguments-error () +(defun %odd-key-arguments-error () (error 'simple-program-error - :format-control "function called with odd number of keyword arguments" + :format-control "function called with odd number of &KEY arguments" :format-arguments nil)) -(defun %unknown-keyword-argument-error (keyword) +(defun %unknown-key-argument-error (key-arg-name) (error 'simple-program-error - :format-control "unknown keyword argument: ~S" - :format-arguments (list keyword))) + :format-control "unknown &KEY argument: ~S" + :format-arguments (list key-arg-name))) (defun %cleanup-point ())