1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
# NanoWasm extensions
MVP WebAssembly was designed as a compact binary encoding designed for small
files, which is often a requirement on a web environment. However, some of
its decisions incur a non-negligible memory and/or performance penalty.
For some interpreters designed for resource-constrained environments, this
might not be desirable or even acceptable.
Therefore, this specification defines a set of third-party extensions,
implemented as [custom sections](BinaryEncoding.md#high-level-structure),
that aim to minimize such penalties, while increasing module file size as a
tradeoff.
The following design decisions were addressed:
## Function body offsets
On the MVP, in order to access the start of a body functions, interpreters are
forced to either:
- Store all function body start offsets in-memory during validation.
- Read all function bodies prior to the function index to be called.
- For example, a [`call`](BinaryEncoding.md#Call-operators) to function
index `90` might require to read many function bodies behind it in order
to retrieve its offset, as every function body has a variable length.
For interpreters that prefer not to rely on dynamically allocated memory
(i.e., a heap) or with little memory available, the former would not be
desirable or even possible to achieve. On the other hand, the latter, while
more memory-efficient, could have a non-negligible impact on performance,
even more so if the module bytecode is read on-the-fly from a "slow",
non-volatile memory e.g.: a SD card, a hard drive disk, a CD-ROM, etc.
Therefore, NanoWasm defines the
[function body offset section](BinaryEncoding.md#nanowasm-function-body-offset-section),
so that interpreters can retrieve the offset of a given function body with
constant-time access.
## Function label offsets
The MVP defines a series of
[control flow operators](Semantics.md#control-constructs-and-instructions) that
perform operations such as branching. Since WebAssembly is defined as a
structured language, some of these operators might require the interpreter to
jump to a given offset within the function that might be defined by an `end`
operator located *below* the current program counter.
Typically, this requires interpreters to read function bodies before
interpretation, which again can be done in different ways:
- Read function bodies on module validation and store label offsets in-memory
for all non-imported functions.
- Read a function body when a `call` operator is found and store its label
offsets in-memory.
Both solutions have significant memory and/or computational time penalties,
which again might be unacceptable for resource-constrained devices. Therefore,
NanoWasm defines the
[label offset section](BinaryEncoding.md#nanowasm-label-offset-section) so that
interpreters can retrieve label offsets with constant-time access, without
having to read the function bodies before hand *and* without having to keep
information in-memory.
|
