Skip to content

Commit 0730891

Browse files
committed
Add extra Canonical ABI note and variant clarification
Resolves #119
1 parent 5754989 commit 0730891

File tree

2 files changed

+18
-10
lines changed

2 files changed

+18
-10
lines changed

design/mvp/CanonicalABI.md

Lines changed: 11 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -116,9 +116,10 @@ def alignment_record(fields):
116116
```
117117

118118
As an optimization, `variant` discriminants are represented by the smallest integer
119-
covering the number of cases in the variant. Depending on the payload type,
120-
this can allow more compact representations of variants in memory. This smallest
121-
integer type is selected by the following function, used above and below:
119+
covering the number of cases in the variant (with cases numbered in order from
120+
`0` to `len(cases)-1`). Depending on the payload type, this can allow more
121+
compact representations of variants in memory. This smallest integer type is
122+
selected by the following function, used above and below:
122123
```python
123124
def alignment_variant(cases):
124125
return max(alignment(discriminant_type(cases)), max_case_alignment(cases))
@@ -366,13 +367,13 @@ guaranteed to be a no-op on the first iteration because the record as
366367
a whole starts out aligned (as asserted at the top of `load`).
367368

368369
Variants are loaded using the order of the cases in the type to determine the
369-
case index. To support the subtyping allowed by `refines`, a lifted variant
370-
value semantically includes a full ordered list of its `refines` case
371-
labels so that the lowering code (defined below) can search this list to find a
372-
case label it knows about. While the code below appears to perform case-label
373-
lookup at runtime, a normal implementation can build the appropriate index
374-
tables at compile-time so that variant-passing is always O(1) and not involving
375-
string operations.
370+
case index, assigning `0` to the first case, `1` to the next case, etc. To
371+
support the subtyping allowed by `refines`, a lifted variant value semantically
372+
includes a full ordered list of its `refines` case labels so that the lowering
373+
code (defined below) can search this list to find a case label it knows about.
374+
While the code below appears to perform case-label lookup at runtime, a normal
375+
implementation can build the appropriate index tables at compile-time so that
376+
variant-passing is always O(1) and not involving string operations.
376377
```python
377378
def load_variant(opts, ptr, cases):
378379
disc_size = size(discriminant_type(cases))

design/mvp/Explainer.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -530,6 +530,13 @@ subtyping. In particular, a `variant` subtype can contain a `case` not present
530530
in the supertype if the subtype's `case` `refines` (directly or transitively)
531531
some `case` in the supertype.
532532

533+
How these abstract values are produced and consumed from Core WebAssembly
534+
values and linear memory is configured by the component via *canonical lifting
535+
and lowering definitions*, which are introduced [below](#canonical-definitions).
536+
For example, while abstract `variant`s contain a list of `case`s labelled by
537+
name, canonical lifting and lowering map each case to an `i32` value starting
538+
at `0`.
539+
533540
The sets of values allowed for the remaining *specialized value types* are
534541
defined by the following mapping:
535542
```

0 commit comments

Comments
 (0)