paul@109 | 1 | Data Structures
|
paul@109 | 2 | ===============
|
paul@109 | 3 |
|
paul@109 | 4 | The fundamental "value type" is a pair of references: one pointing to the
|
paul@109 | 5 | referenced object represented by the interchangeable value; one referring to
|
paul@109 | 6 | the context of the referenced object, typically the object through which the
|
paul@109 | 7 | referenced object was acquired as an attribute.
|
paul@109 | 8 |
|
paul@109 | 9 | Value Layout
|
paul@109 | 10 | ------------
|
paul@109 | 11 |
|
paul@109 | 12 | 0 1
|
paul@109 | 13 | object context
|
paul@109 | 14 | reference reference
|
paul@109 | 15 |
|
paul@109 | 16 | Acquiring Values
|
paul@109 | 17 | ----------------
|
paul@109 | 18 |
|
paul@109 | 19 | Values are acquired through name lookups and attribute access, yielding
|
paul@109 | 20 | the appropriate object reference together with a context reference as
|
paul@109 | 21 | indicated in the following table:
|
paul@109 | 22 |
|
paul@109 | 23 | Type of Access Context Notes
|
paul@109 | 24 | -------------- ------- -----
|
paul@109 | 25 |
|
paul@109 | 26 | Local name Preserved Functions provide no context
|
paul@109 | 27 |
|
paul@109 | 28 | Global name Preserved Modules provide no context
|
paul@109 | 29 |
|
paul@109 | 30 | Class-originating Accessor Class accessor preserves the stored
|
paul@109 | 31 | attribute -or- context; instance accessor overrides
|
paul@109 | 32 | Preserved the stored context if it is null or
|
paul@109 | 33 | belongs to the instance's class
|
paul@109 | 34 | hierarchy
|
paul@109 | 35 |
|
paul@109 | 36 | Instance-originating Preserved Methods retain their original context
|
paul@109 | 37 | attribute
|
paul@109 | 38 |
|
paul@109 | 39 | There may be some scope for simplifying the above, to the detriment of Python
|
paul@109 | 40 | compatibility, since the unbound vs. bound methods situation can be confusing.
|
paul@109 | 41 |
|
paul@109 | 42 | Manipulating Values
|
paul@109 | 43 | -------------------
|
paul@109 | 44 |
|
paul@109 | 45 | According to the table describing value acquisition, different instructions
|
paul@109 | 46 | must implement different operations when acquiring values:
|
paul@109 | 47 |
|
paul@109 | 48 | Instruction Purpose Context Operations
|
paul@109 | 49 | ----------- ------- ------------------
|
paul@109 | 50 |
|
paul@109 | 51 | LoadConst Load class, function, Combine null context with loaded
|
paul@109 | 52 | module, constant object
|
paul@109 | 53 |
|
paul@109 | 54 | LoadAddress Load attribute from Classes, functions and modules
|
paul@109 | 55 | known object stored as cause the loaded attribute to be
|
paul@109 | 56 | an attribute retrieved unchanged; whereas
|
paul@109 | 57 | constants (representing instances)
|
paul@109 | 58 | cause the constant to override the
|
paul@109 | 59 | attribute's own context (since all
|
paul@109 | 60 | attributes should belong to the
|
paul@109 | 61 | constant's class hierarchy)
|
paul@109 | 62 |
|
paul@109 | 63 | LoadAttr Load attribute from Attributes with null contexts or
|
paul@109 | 64 | instance stored as an contexts compatible with the
|
paul@109 | 65 | attribute instance cause loaded attributes
|
paul@109 | 66 | to combine the instance as context
|
paul@109 | 67 | with the object from the
|
paul@109 | 68 | attribute; other attributes have
|
paul@109 | 69 | their context preserved
|
paul@109 | 70 |
|
paul@109 | 71 | LoadAttrIndex Load attribute from Classes, functions and modules as
|
paul@109 | 72 | unknown object stored the unknown object accessor cause
|
paul@109 | 73 | as an attribute the loaded attribute to be
|
paul@109 | 74 | retrieved unchanged; whereas
|
paul@109 | 75 | instances cause the LoadAttr rules
|
paul@109 | 76 | to apply
|
paul@109 | 77 |
|
paul@109 | 78 | Consequently, a certain amount of run-time testing is required for both
|
paul@109 | 79 | LoadAttr and LoadAttrIndex.
|
paul@109 | 80 |
|
paul@109 | 81 | Objects
|
paul@109 | 82 | -------
|
paul@109 | 83 |
|
paul@109 | 84 | Since classes, functions and instances are all "objects", each must support
|
paul@109 | 85 | certain features and operations in the same way.
|
paul@109 | 86 |
|
paul@109 | 87 | The __class__ Attribute
|
paul@109 | 88 | -----------------------
|
paul@109 | 89 |
|
paul@109 | 90 | All objects support the __class__ attribute:
|
paul@109 | 91 |
|
paul@109 | 92 | Class: refers to the type class (type.__class__ also refers to the type class)
|
paul@109 | 93 | Function: refers to the function class
|
paul@109 | 94 | Instance: refers to the class instantiated to make the object
|
paul@109 | 95 |
|
paul@109 | 96 | Invocation
|
paul@109 | 97 | ----------
|
paul@109 | 98 |
|
paul@109 | 99 | The following actions need to be supported:
|
paul@109 | 100 |
|
paul@109 | 101 | Class: create instance, call __init__ with instance, return object
|
paul@109 | 102 | Function: call function body, return result
|
paul@109 | 103 | Instance: call __call__ method, return result
|
paul@109 | 104 |
|
paul@109 | 105 | Structure Layout
|
paul@109 | 106 | ----------------
|
paul@109 | 107 |
|
paul@109 | 108 | A suitable structure layout might be something like this:
|
paul@109 | 109 |
|
paul@109 | 110 | Identifier Address Type Object ...
|
paul@109 | 111 |
|
paul@109 | 112 | 0 1 2 3 4
|
paul@109 | 113 | classcode invocation __class__ attribute ...
|
paul@109 | 114 | reference reference reference
|
paul@109 | 115 |
|
paul@109 | 116 | Here, the classcode refers to the attribute lookup table for the object. Since
|
paul@109 | 117 | classes and instances share the same classcode, they might resemble the
|
paul@109 | 118 | following:
|
paul@109 | 119 |
|
paul@109 | 120 | Class C:
|
paul@109 | 121 |
|
paul@109 | 122 | 0 1 2 3 4
|
paul@109 | 123 | code for C __new__ class type attribute ...
|
paul@109 | 124 | reference reference reference
|
paul@109 | 125 |
|
paul@109 | 126 | Instance of C:
|
paul@109 | 127 |
|
paul@109 | 128 | 0 1 2 3 4
|
paul@109 | 129 | code for C C.__call__ class C attribute ...
|
paul@109 | 130 | reference reference reference
|
paul@109 | 131 | (if exists)
|
paul@109 | 132 |
|
paul@109 | 133 | The __new__ reference would lead to code consisting of the following
|
paul@109 | 134 | instructions:
|
paul@109 | 135 |
|
paul@109 | 136 | create instance for C
|
paul@109 | 137 | call C.__init__(instance, ...)
|
paul@109 | 138 | return instance
|
paul@109 | 139 |
|
paul@109 | 140 | If C has a __call__ attribute, the invocation "slot" of C instances would
|
paul@109 | 141 | refer to the same thing as C.__call__.
|
paul@109 | 142 |
|
paul@109 | 143 | For functions, the same general layout applies:
|
paul@109 | 144 |
|
paul@109 | 145 | Function f:
|
paul@109 | 146 |
|
paul@109 | 147 | 0 1 2 3 4
|
paul@109 | 148 | code for code class attribute ...
|
paul@109 | 149 | function reference function reference
|
paul@109 | 150 | reference
|
paul@109 | 151 |
|
paul@109 | 152 | Here, the code reference would lead to code for the function. Note that the
|
paul@109 | 153 | function locals are completely distinct from this structure and are not
|
paul@109 | 154 | comparable to attributes. Instead, attributes are reserved for default
|
paul@109 | 155 | parameter values.
|
paul@109 | 156 |
|
paul@109 | 157 | For modules, there is no meaningful invocation reference:
|
paul@109 | 158 |
|
paul@109 | 159 | Module m:
|
paul@109 | 160 |
|
paul@109 | 161 | 0 1 2 3 4
|
paul@109 | 162 | code for m (unused) module type attribute ...
|
paul@109 | 163 | reference (global)
|
paul@109 | 164 | reference
|
paul@109 | 165 |
|
paul@109 | 166 | Both classes and modules have code in their definitions, but this would be
|
paul@109 | 167 | generated in order and not referenced externally.
|
paul@109 | 168 |
|
paul@109 | 169 | Invocation Operation
|
paul@109 | 170 | --------------------
|
paul@109 | 171 |
|
paul@109 | 172 | Consequently, regardless of the object an invocation is always done as
|
paul@109 | 173 | follows:
|
paul@109 | 174 |
|
paul@109 | 175 | get invocation reference (at object+1)
|
paul@109 | 176 | jump to reference
|
paul@109 | 177 |
|
paul@109 | 178 | Additional preparation is necessary before the above code: positional
|
paul@109 | 179 | arguments must be saved to the parameter stack, and keyword arguments must be
|
paul@109 | 180 | resolved and saved to the appropriate position in the parameter stack.
|
paul@109 | 181 |
|
paul@109 | 182 | Attribute Operations
|
paul@109 | 183 | --------------------
|
paul@109 | 184 |
|
paul@109 | 185 | Attribute access needs to go through the attribute lookup table. Some
|
paul@109 | 186 | optimisations are possible and are described in the appropriate section.
|
paul@109 | 187 |
|
paul@109 | 188 | One important aspect of attribute access is the appropriate setting of the
|
paul@109 | 189 | context in the acquired attribute value. From the table describing the
|
paul@109 | 190 | acquisition of values, it is clear that the principal exception is that where
|
paul@109 | 191 | a class-originating attribute is accessed on an instance. Consequently, the
|
paul@109 | 192 | following algorithm could be employed once an attribute has been located:
|
paul@109 | 193 |
|
paul@109 | 194 | 1. If the attribute's context is a special value, indicating that it should
|
paul@109 | 195 | be replaced upon instance access, then proceed to the next step;
|
paul@109 | 196 | otherwise, acquire both the context and the object as they are.
|
paul@109 | 197 |
|
paul@109 | 198 | 2. If the accessor is an instance, use that as the value's context, acquiring
|
paul@109 | 199 | only the object from the attribute.
|
paul@109 | 200 |
|
paul@109 | 201 | Where accesses can be determined ahead of time (as discussed in the
|
paul@109 | 202 | optimisations section), the above algorithm may not necessarily be employed in
|
paul@109 | 203 | the generated code for some accesses.
|