1 files changed, 62 insertions, 0 deletions
diff --git a/NanoWasm.md b/NanoWasm.md
new file mode 100644
index 0000000..900bda6
--- /dev/null
+++ b/NanoWasm.md
@@ -0,0 +1,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.