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