paul@15 | 1 | Namespace Definition
|
paul@15 | 2 | ====================
|
paul@15 | 3 |
|
paul@15 | 4 | Module attributes are defined either at the module level or by global
|
paul@15 | 5 | statements.
|
paul@15 | 6 |
|
paul@15 | 7 | Class attributes are defined only within class statements.
|
paul@15 | 8 |
|
paul@15 | 9 | Instance attributes are defined only by assignments to attributes of self
|
paul@15 | 10 | within __init__ methods.
|
paul@15 | 11 |
|
paul@11 | 12 | Data Structures
|
paul@11 | 13 | ===============
|
paul@11 | 14 |
|
paul@11 | 15 | Since classes, functions and instances are all "objects", each must support
|
paul@11 | 16 | certain features and operations in the same way.
|
paul@11 | 17 |
|
paul@11 | 18 | The __class__ Attribute
|
paul@11 | 19 | -----------------------
|
paul@11 | 20 |
|
paul@11 | 21 | All objects support the __class__ attribute:
|
paul@11 | 22 |
|
paul@11 | 23 | Class: refers to the type class (type.__class__ also refers to the type class)
|
paul@11 | 24 | Function: refers to the function class
|
paul@11 | 25 | Instance: refers to the class instantiated to make the object
|
paul@11 | 26 |
|
paul@11 | 27 | Invocation
|
paul@11 | 28 | ----------
|
paul@11 | 29 |
|
paul@11 | 30 | The following actions need to be supported:
|
paul@11 | 31 |
|
paul@11 | 32 | Class: create instance, call __init__ with instance, return object
|
paul@11 | 33 | Function: call function body, return result
|
paul@11 | 34 | Instance: call __call__ method, return result
|
paul@11 | 35 |
|
paul@11 | 36 | Structure Layout
|
paul@11 | 37 | ----------------
|
paul@11 | 38 |
|
paul@11 | 39 | A suitable structure layout might be something like this:
|
paul@11 | 40 |
|
paul@11 | 41 | 0 1 2 3 4
|
paul@11 | 42 | classcode invocation __class__ attribute ...
|
paul@11 | 43 | reference reference reference
|
paul@11 | 44 |
|
paul@11 | 45 | Here, the classcode refers to the attribute lookup table for the object. Since
|
paul@11 | 46 | classes and instances share the same classcode, they might resemble the
|
paul@11 | 47 | following:
|
paul@11 | 48 |
|
paul@11 | 49 | Class C:
|
paul@11 | 50 |
|
paul@11 | 51 | 0 1 2 3 4
|
paul@11 | 52 | code for C __new__ class type attribute ...
|
paul@11 | 53 | reference reference reference
|
paul@11 | 54 |
|
paul@11 | 55 | Instance of C:
|
paul@11 | 56 |
|
paul@11 | 57 | 0 1 2 3 4
|
paul@11 | 58 | code for C C.__call__ class C attribute ...
|
paul@11 | 59 | reference reference reference
|
paul@11 | 60 | (if exists)
|
paul@11 | 61 |
|
paul@11 | 62 | The __new__ reference would lead to code consisting of the following
|
paul@11 | 63 | instructions:
|
paul@11 | 64 |
|
paul@11 | 65 | create instance for C
|
paul@11 | 66 | call C.__init__(instance, ...)
|
paul@11 | 67 | return instance
|
paul@11 | 68 |
|
paul@11 | 69 | If C has a __call__ attribute, the invocation "slot" of C instances would
|
paul@11 | 70 | refer to the same thing as C.__call__.
|
paul@11 | 71 |
|
paul@11 | 72 | For functions, the same general layout applies:
|
paul@11 | 73 |
|
paul@11 | 74 | Function f:
|
paul@11 | 75 |
|
paul@11 | 76 | 0 1 2 3 4
|
paul@11 | 77 | code for code class attribute ...
|
paul@11 | 78 | function reference function reference
|
paul@11 | 79 | reference
|
paul@11 | 80 |
|
paul@11 | 81 | Here, the code reference would lead to code for the function.
|
paul@11 | 82 |
|
paul@11 | 83 | Invocation Operation
|
paul@11 | 84 | --------------------
|
paul@11 | 85 |
|
paul@11 | 86 | Consequently, regardless of the object an invocation is always done as
|
paul@11 | 87 | follows:
|
paul@11 | 88 |
|
paul@11 | 89 | get invocation reference (at object+1)
|
paul@11 | 90 | jump to reference
|
paul@11 | 91 |
|
paul@11 | 92 | Additional preparation is necessary before the above code: positional
|
paul@11 | 93 | arguments must be saved to the parameter stack, and keyword arguments must be
|
paul@11 | 94 | resolved and saved to the appropriate position in the parameter stack.
|
paul@11 | 95 |
|
paul@11 | 96 | Attribute Operations
|
paul@11 | 97 | --------------------
|
paul@11 | 98 |
|
paul@11 | 99 | Attribute access needs to go through the attribute lookup table.
|
paul@21 | 100 |
|
paul@21 | 101 | Instruction Evaluation Model
|
paul@21 | 102 | ============================
|
paul@21 | 103 |
|
paul@21 | 104 | Programs use a value stack where evaluated instructions may save their
|
paul@21 | 105 | results. A value stack pointer indicates the top of this stack. In addition, a
|
paul@21 | 106 | separate stack is used to record the invocation frames. All stack pointers
|
paul@21 | 107 | refer to the next address to be used by the stack, not the address of the
|
paul@21 | 108 | uppermost element.
|
paul@21 | 109 |
|
paul@21 | 110 | Frame Stack Value Stack
|
paul@21 | 111 | ----------- ----------- Address of Callable
|
paul@21 | 112 | -------------------
|
paul@21 | 113 | previous ...
|
paul@21 | 114 | current ------> callable -----> identifier
|
paul@21 | 115 | arg1 reference to code
|
paul@21 | 116 | arg2
|
paul@21 | 117 | arg3
|
paul@21 | 118 | local4
|
paul@21 | 119 | local5
|
paul@21 | 120 | ...
|
paul@21 | 121 |
|
paul@21 | 122 | Loading local names is a matter of performing frame-relative accesses to the
|
paul@21 | 123 | value stack.
|
paul@21 | 124 |
|
paul@21 | 125 | Invocations and Argument Evaluation
|
paul@21 | 126 | -----------------------------------
|
paul@21 | 127 |
|
paul@21 | 128 | When preparing for an invocation, the caller first sets the invocation frame
|
paul@21 | 129 | pointer. Then, positional arguments are added to the stack such that the first
|
paul@21 | 130 | argument positions are filled. A number of stack locations for the remaining
|
paul@21 | 131 | arguments specified in the program are then reserved. The names of keyword
|
paul@21 | 132 | arguments are used (in the form of table index values) to consult the
|
paul@21 | 133 | parameter table and to find the location in which such arguments are to be
|
paul@21 | 134 | stored.
|
paul@21 | 135 |
|
paul@21 | 136 | fn(a, b, d=1, e=2, c=3) -> fn(a, b, c, d, e)
|
paul@21 | 137 |
|
paul@21 | 138 | Value Stack
|
paul@21 | 139 | -----------
|
paul@21 | 140 |
|
paul@21 | 141 | ... ... ... ...
|
paul@21 | 142 | fn fn fn fn
|
paul@21 | 143 | a a a a
|
paul@21 | 144 | b b b b
|
paul@21 | 145 | ___ ___ ___ --> 3
|
paul@21 | 146 | ___ --> 1 1 | 1
|
paul@21 | 147 | ___ | ___ --> 2 | 2
|
paul@21 | 148 | 1 ----------- 2 ----------- 3 -----------
|
paul@21 | 149 |
|
paul@21 | 150 | Conceptually, the frame can be considered as a collection of attributes, as
|
paul@21 | 151 | seen in other kinds of structures:
|
paul@21 | 152 |
|
paul@21 | 153 | Frame for invocation of fn:
|
paul@21 | 154 |
|
paul@21 | 155 | 0 1 2 3 4 5
|
paul@21 | 156 | code a b c d e
|
paul@21 | 157 | reference
|
paul@21 | 158 |
|
paul@21 | 159 | However, where arguments are specified positionally, such "attributes" are not
|
paul@21 | 160 | set using a comparable approach to that employed with other structures.
|
paul@21 | 161 | Keyword arguments are set using an attribute-like mechanism, though, where the
|
paul@21 | 162 | position of each argument discovered using the parameter table.
|
paul@21 | 163 |
|
paul@21 | 164 | Tuples, Frames and Allocation
|
paul@21 | 165 | -----------------------------
|
paul@21 | 166 |
|
paul@21 | 167 | Using the approach where arguments are treated like attributes in some kind of
|
paul@21 | 168 | structure, we could choose to allocate frames in places other than a stack.
|
paul@21 | 169 | This would produce something somewhat similar to a plain tuple object.
|
paul@23 | 170 |
|
paul@23 | 171 | Optimisations
|
paul@23 | 172 | =============
|
paul@23 | 173 |
|
paul@28 | 174 | Constant Attributes
|
paul@28 | 175 | -------------------
|
paul@28 | 176 |
|
paul@23 | 177 | Where attributes of modules, classes and instances are only set once and are
|
paul@23 | 178 | effectively constant, it should be possible to circumvent the attribute lookup
|
paul@28 | 179 | mechanism and to directly reference the attribute value. This technique may
|
paul@28 | 180 | only be considered applicable in the following cases for "container" objects:
|
paul@28 | 181 |
|
paul@28 | 182 | 1. For modules, provided that assignments to module attributes are only
|
paul@28 | 183 | permitted within the module itself either at the top-level or via names
|
paul@28 | 184 | declared as globals. Thus, the following would not be permitted:
|
paul@28 | 185 |
|
paul@28 | 186 | another_module.this_module.attr = value
|
paul@28 | 187 |
|
paul@28 | 188 | (Where this_module is a reference to the current module.)
|
paul@28 | 189 |
|
paul@28 | 190 | 2. For classes, provided that assignments to class attributes are only
|
paul@28 | 191 | permitted within the class definition, outside methods. This would mean
|
paul@28 | 192 | that classes would be "sealed" at definition time (like functions).
|
paul@28 | 193 |
|
paul@28 | 194 | Unlike the property of function locals that they may only sensibly be accessed
|
paul@28 | 195 | within the function in which they reside, these cases demand additional
|
paul@28 | 196 | controls or assumptions on or about access to the stored data. Meanwhile, it
|
paul@28 | 197 | would be difficult to detect eligible attributes on arbitrary instances due to
|
paul@28 | 198 | the need for some kind of type inference or abstract execution.
|
paul@28 | 199 |
|
paul@28 | 200 | Where (1) and (2) apply, any attribute with only one recorded assignment on it
|
paul@28 | 201 | can be considered a constant attribute and this eligible for this
|
paul@28 | 202 | optimisation, the consequence of which would be the replacement of a
|
paul@28 | 203 | LoadAttrIndex instruction (which needs to look up an attribute using the
|
paul@28 | 204 | run-time details of the "container" and the compile-time details of the
|
paul@28 | 205 | attribute) with a LoadAttr instruction.
|
paul@28 | 206 |
|
paul@28 | 207 | Constant Attribute Values
|
paul@28 | 208 | -------------------------
|
paul@28 | 209 |
|
paul@28 | 210 | Where an attribute value is itself constant and be used either in an operation
|
paul@28 | 211 | accessing its own attributes, or in an invocation, the value can be directly
|
paul@28 | 212 | inspected for optimisations or employed in the generated code. For the
|
paul@28 | 213 | attribute values themselves, only objects of a constant nature may be
|
paul@28 | 214 | considered suitable for this particular optimisation:
|
paul@28 | 215 |
|
paul@28 | 216 | * Functions
|
paul@28 | 217 | * Classes
|
paul@28 | 218 | * Modules
|
paul@28 | 219 | * Instances defined as constant literals
|
paul@28 | 220 |
|
paul@28 | 221 | This is because arbitrary objects (such as most instances) have no
|
paul@28 | 222 | well-defined form before run-time and cannot be investigated further at
|
paul@28 | 223 | compile-time or have a representation inserted into the generated code.
|