Design of CMU Common Lisp.pdf - Common Lisp.net

More documents

Recommendations

Info

Chapter 11 ICR finalize This pass looks for interesting things in the ICR so that we can forget about them. Used and not defined things are flamed about. We postpone these checks until now because the ICR optimizations may discover errors that are not initially obvious. We also emit efficiency notes about optimizations that we were unable to do. We can’t emit the notes immediately, since we don’t know for sure whether a repeated attempt at optimization will succeed. We examine all references to unknown global function variables and update the approximate type accordingly. We also record the names of the unknown functions so that they can be flamed about if they are never defined. Unknown normal variables are flamed about on the fly during ICR conversion, so we ignore them here. We check each newly defined global function for compatibility with previously recorded type information. If there is no :defined or :declared type, then we check for compatibility with any approximate function type inferred from previous uses. 32
Chapter 12 Environment analysis A related change would be to annotate ICR with information about tail-recursion relations. What we would do is add a slot to the node structure that points to the corresponding Tail-Info when a node is in a TR position. This annotation would be made in a final ICR pass that runs after cleanup code is generated (part of environment analysis). When true, the node is in a true TR position (modulo return-convention incompatibility). When we determine return conventions, we null out the tail-p slots in XEP calls or known calls where we decided not to preserve tail-recursion. In this phase, we also check for changes in the dynamic binding environment that require cleanup code to be generated. We just check for changes in the Continuation-Cleanup on local control transfers. If it changes from an inner dynamic context to an outer one that is in the same environment, then we emit code to clean up the dynamic bindings between the old and new continuation. We represent the result of cleanup detection to the back end by interposing a new block containing a call to a funny function. Local exits from CATCH or UNWIND-PROTECT are detected in the same way. —# The primary activity in environment analysis is the annotation of ICR with environment structures describing where variables are allocated and what values the environment closes over. Each lambda points to the environment where its variables are allocated, and the environments point back. We always allocate the environment at the Bind node for the sole non-let lambda in the environment, so there is a close relationship between environments and functions. Each ”real function” (i.e. not a LET) has a corresponding environment. We attempt to share the same environment among as many lambdas as possible so that unnecessary environment manipulation is not done. During environment analysis the only optimization of this sort is realizing that a Let (a lambda with no Return node) cannot need its own environment, since there is no way that it can return and discover that its old values have been clobbered. When the function is called, values from other environments may need to be made available in the function’s environment. These values are said to be ”closed over”. Even if a value is not referenced in a given environment, it may need to be closed over in that environment so that it can be passed to a called function that does reference the value. When we discover that a value must be closed over by a function, we must close over the value in all the environments where that function is referenced. This applies to all references, not just local calls, since at other references we must have the values on hand so that we can build a closure. This propagation must be applied recursively, since the value must also be available in *those* functions’ callers. If a closure reference is known to be ”safe” (not an upward funarg), then the closure structure may be allocated on the stack. Closure analysis deals only with closures over values, while Common Lisp requires closures over variables. The difference only becomes significant when variables are set. If a variable is not set, then we can freely make copies of it without keeping track of where they are. When a variable is set, we must maintain a single value cell, or at least the illusion thereof. We achieve this by creating a heap-allocated ”value cell” structure for each set variable that is closed over. The pointer to this value cell is passed around as the ”value” corresponding to that variable. References to the variable must explicitly indirect through the value cell. When we are scanning over the lambdas in the component, we also check for bound but not referenced 33
Page 1 and 2: Design of CMU Common Lisp Robert A.
Page 3 and 4: Contents I System Architecture 2 1
Page 5 and 6: 32.2 Calls . . . . . . . . . . . .
Page 7 and 8: Part I System Architecture 5
Page 9 and 10: lisp Originally, this package had a
Page 11 and 12: 2.3 Building Core Images Both the k
Page 13 and 14: Chapter 3 Compiler Overview The str
Page 15 and 16: Chapter 4 The Implicit Continuation
Page 17 and 18: What is the relationship between th
Page 19 and 20: We actually convert each form in th
Page 21 and 22: Actually, I guess the overhead for
Page 23 and 24: The current node type annotations s
Page 25 and 26: Chapter 7 Find components This is a
Page 27 and 28: The big reason for doing this trans
Page 29 and 30: • Eliminate IFs with predicates k
Page 31 and 32: If there is no intersection between
Page 33: could punt on set variables...] A t
Page 37 and 38: Chapter 13 Virtual Machine Represen
Page 39 and 40: If the tail-set type is for a fixed
Page 41 and 42: can use the node-derived-type to se
Page 43 and 44: ack branch in a loop the drop-thru,
Page 45 and 46: The primitive type T is special-cas
Page 47 and 48: But the problem doesn’t happen he
Page 49 and 50: Chapter 19 Representation selection
Page 51 and 52: This phase makes use of the results
Page 53 and 54: Chapter 21 Packing File: pack #—
Page 55 and 56: Subject to resource constraints: -
Page 57 and 58: Chapter 22 Code generation This is
Page 59 and 60: Chapter 24 Dumping So far as input
Page 61 and 62: Chapter 25 User Interface of the Co
Page 63 and 64: Chapter 26 Retargeting the compiler
Page 65 and 66: Chapter 27 Storage bases and classe
Page 67 and 68: Chapter 28 Type system parameteriza
Page 69 and 70: ead in any order as long no TN is w
Page 71 and 72: Chapter 31 Writing Assembly Code VO
Page 73 and 74: 32.1 Function Call 32.1.1 Registers
Page 75 and 76: Register usage at the time of the r
Page 77 and 78: when (current-nfp-tn VOP-self-point
Page 79 and 80: Chapter 33 Standard Primitives 77
Page 81 and 82: it would seem pretty losing to sepa
Page 83 and 84: Chapter 35 The Type System 81
Page 85 and 86:
Chapter 37 The IR1 Interpreter May
Page 87 and 88:
editor-based mouse-driven interface
Page 89 and 90:
254 => read next two bytes for inte
Page 91 and 92:
location name, type, etc. location-
Page 93 and 94:
Then the debug-info holds a simple-
Page 95 and 96:
Chapter 39 Object Format 39.1 Taggi
Page 97 and 98:
39.5 Other-immediates As for fixnum
Page 99 and 100:
structure-header-type 182 fdefn-typ
Page 101 and 102:
Available Elements: This is a fixnu
Page 103 and 104:
| Pointer to next function (other-p
Page 105 and 106:
NIL eval::*top-of-stack* lisp::*cur
Page 107 and 108:
Chapter 41 Interface to C and Assem
Page 109 and 110:
Chapter 43 Core File Format 107
Page 111 and 112:
language. The body of necessity beg
Page 113 and 114:
15: FOP-LIST length(1) ⇒ stack Th
Page 115 and 116:
59: FOP-SMALL-CODE nitems(1) size(2
Page 117 and 118:
149-199: Unused 200: FOP-RPLACA tab
Page 119 and 120:
closed continuation A closed contin
Page 121 and 122:
Data-block A data-block is a dual-w
show all

Design of CMU Common Lisp.pdf - Common Lisp.net

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?