@@ -11,6 +11,8 @@ being specified here.
11
11
* [ Despecialization] ( #despecialization )
12
12
* [ Alignment] ( #alignment )
13
13
* [ Element Size] ( #element-size )
14
+ * [ Call Context] ( #call-context )
15
+ * [ Canonical ABI Options] ( #canonical-abi-options )
14
16
* [ Runtime State] ( #runtime-state )
15
17
* [ Loading] ( #loading )
16
18
* [ Storing] ( #storing )
@@ -223,17 +225,21 @@ def num_i32_flags(labels):
223
225
return math.ceil(len (labels) / 32 )
224
226
```
225
227
226
- ### Runtime State
228
+ ### Call Context
227
229
228
230
The subsequent definitions of loading and storing a value from linear memory
229
- require additional runtime state, which is threaded through most subsequent
230
- definitions via the ` cx ` parameter of type ` CallContext ` :
231
+ require additional configuration and state, which is threaded through most
232
+ subsequent definitions via the ` cx ` parameter of type ` CallContext ` :
231
233
``` python
232
234
@dataclass
233
235
class CallContext :
234
236
opts: CanonicalOptions
235
237
inst: ComponentInstance
236
238
```
239
+ Note that the ` Task ` and ` Subtask ` classes defined below derive ` CallContext ` ,
240
+ adding additional state only used for export and import calls, resp.
241
+
242
+ ### Canonical ABI Options
237
243
238
244
The ` opts ` field of ` CallContext ` contains all the possible ` canonopt `
239
245
immediates that can be passed to the ` canon ` definition being implemented.
@@ -247,6 +253,11 @@ class CanonicalOptions:
247
253
sync: bool = True # = !canonopt.async
248
254
callback: Optional[Callable] = None
249
255
```
256
+ (Note that the ` async ` ` canonopt ` is inverted to ` sync ` here for the practical
257
+ reason that ` async ` is a keyword and most branches below want to start with the
258
+ ` sync = True ` case.)
259
+
260
+ ### Runtime State
250
261
251
262
The ` inst ` field of ` CallContext ` points to the component instance which the
252
263
` canon ` -generated function is closed over. Component instances contain all the
@@ -1499,8 +1510,8 @@ With only the definitions above, the Canonical ABI would be forced to place all
1499
1510
parameters and results in linear memory. While this is necessary in the general
1500
1511
case, in many cases performance can be improved by passing small-enough values
1501
1512
in registers by using core function parameters and results. To support this
1502
- optimization, the Canonical ABI defines ` flatten ` to map component function
1503
- types to core function types by attempting to decompose all the
1513
+ optimization, the Canonical ABI defines ` flatten_functype ` to map component
1514
+ function types to core function types by attempting to decompose all the
1504
1515
non-dynamically-sized component value types into core value types.
1505
1516
1506
1517
For a variety of [ practical] [ Implementation Limits ] reasons, we need to limit
@@ -1519,7 +1530,7 @@ have already allocated space for the return value (e.g., efficiently on the
1519
1530
stack), passing in an ` i32 ` pointer as an parameter instead of returning an
1520
1531
` i32 ` as a return value.
1521
1532
1522
- Given all this, the top-level definition of ` flatten ` is:
1533
+ Given all this, the top-level definition of ` flatten_functype ` is:
1523
1534
``` python
1524
1535
MAX_FLAT_PARAMS = 16
1525
1536
MAX_FLAT_RESULTS = 1
@@ -1881,7 +1892,7 @@ def lift_heap_values(cx, vi, ts):
1881
1892
1882
1893
Symmetrically, the ` lower_flat_values ` function defines how to lower a
1883
1894
list of component-level values ` vs ` of types ` ts ` into a list of core
1884
- values. As already described for [ ` flatten ` ] ( #flattening ) above,
1895
+ values. As already described for [ ` flatten_functype ` ] ( #flattening ) above,
1885
1896
lowering handles the greater-than-` max_flat ` case by either allocating
1886
1897
storage with ` realloc ` or accepting a caller-allocated buffer as an
1887
1898
out-param:
0 commit comments