Structured stack (#813)

* Rename AstSemantics.md to Semantics.md

* Rewrite Semantics for structured stack machine

* Update control instructions

* Update nop

* More tweaks

* Update README.md

* Update Semantics.md

* Update Semantics.md

* Address @rossberg-chromium comments

BinaryEncoding.md

@@ -50,7 +50,7 @@ represented by _at most_ ceil(_N_/7) bytes that may contain padding `0x80` or `0
 Note: Currently, the only sizes used are `varint32` and `varint64`.
 
 ### `value_type`
-A single-byte unsigned integer indicating a [value type](AstSemantics.md#types). These types are encoded as:
+A single-byte unsigned integer indicating a [value type](Semantics.md#types). These types are encoded as:
 * `1` indicating type `i32` 
 * `2` indicating type `i64` 
 * `3` indicating type `f32` 
@@ -73,7 +73,7 @@ A single-byte unsigned integer indicating the kind of definition being imported
 
 ### `resizable_limits`
 A packed tuple that describes the limits of a
-[table](AstSemantics.md#table) or [memory](AstSemantics.md#resizing):
+[table](Semantics.md#table) or [memory](Semantics.md#resizing):
 
 | Field | Type | Description |
 | ----- |  ----- | ----- |
@@ -192,7 +192,7 @@ or, if the `kind` is `Table`:
 
 | Field | Type | Description |
 | ----- | ---- | ----------- |
-| element_type | `varuint7` | `0x20`, indicating [`anyfunc`](AstSemantics.md#table) |
+| element_type | `varuint7` | `0x20`, indicating [`anyfunc`](Semantics.md#table) |
 | | `resizable_limits` | see [above](#resizable_limits) |
 
 or, if the `kind` is `Memory`:
@@ -229,7 +229,7 @@ The encoding of a [Table section](Modules.md#table-section):
 
 | Field | Type | Description |
 | ----- | ---- | ----------- |
-| element_type | `varuint7` | `0x20`, indicating [`anyfunc`](AstSemantics.md#table) |
+| element_type | `varuint7` | `0x20`, indicating [`anyfunc`](Semantics.md#table) |
 | | `resizable_limits` | see [above](#resizable_limits) |
 
 In the MVP, the number of tables must be no more than 1.
@@ -250,7 +250,7 @@ The encoding of a [Memory section](Modules.md#linear-memory-section):
 | | `resizable_limits` | see [above](#resizable_limits) |
 
 Note that the initial/maximum fields are specified in units of 
-[WebAssembly pages](AstSemantics.md#linear-memory).
+[WebAssembly pages](Semantics.md#linear-memory).
 
 In the MVP, the number of memories must be no more than 1.
 
@@ -399,7 +399,7 @@ count may be greater or less than the actual number of locals.
 # Function Bodies
 
 Function bodies consist of a sequence of local variable declarations followed by 
-[bytecode instructions](AstSemantics.md). Each function body must end with the `end` opcode.
+[bytecode instructions](Semantics.md). Each function body must end with the `end` opcode.
 
 | Field | Type | Description |
 | ----- | ---- | ----------- |
@@ -420,7 +420,7 @@ It is legal to have several entries with the same type.
 | type | `value_type` | type of the variables |
 
 
-## Control flow operators ([described here](AstSemantics.md#control-flow-structures))
+## Control flow operators ([described here](Semantics.md#control-flow-structures))
 
 | Name | Opcode | Immediates | Description |
 | ---- | ---- | ---- | ---- |
@@ -454,7 +454,7 @@ The `br_table` operator implements an indirect branch. It accepts an optional va
 branches to the block or loop at the given offset within the `target_table`. If the input value is 
 out of range, `br_table` branches to the default target.
 
-## Basic operators ([described here](AstSemantics.md#constants))
+## Basic operators ([described here](Semantics.md#constants))
 
 | Name | Opcode | Immediates | Description |
 | ---- | ---- | ---- | ---- |
@@ -472,7 +472,7 @@ out of range, `br_table` branches to the default target.
 
 The `call_indirect` operator takes a list of function arguments and as the last operand the index into the table.
 
-## Memory-related operators ([described here](AstSemantics.md#linear-memory-accesses))
+## Memory-related operators ([described here](Semantics.md#linear-memory-accesses))
 
 | Name | Opcode | Immediate | Description |
 | ---- | ---- | ---- | ---- |
@@ -515,7 +515,7 @@ natural alignment. The bits after the
 `log(memory-access-size)` least-significant bits must be set to 0. These bits are reserved for future use
 (e.g., for shared memory ordering requirements).
 
-## Simple operators ([described here](AstSemantics.md#32-bit-integer-operators))
+## Simple operators ([described here](Semantics.md#32-bit-integer-operators))
 
 | Name | Opcode | Immediate | Description |
 | ---- | ---- | ---- | ---- |

CAndC++.md

@@ -88,7 +88,7 @@ optimizers still assume that undefined behavior won't occur, so such bugs
 can still lead to surprising behavior.
 
 For example, while unaligned memory access is
-[fully defined](AstSemantics.md#alignment) in WebAssembly, C and C++ compilers
+[fully defined](Semantics.md#alignment) in WebAssembly, C and C++ compilers
 make no guarantee that a (non-packed) unaligned memory access at the source
 level is harmlessly translated into an unaligned memory access in WebAssembly.
 And in practice, popular C and C++ compilers do optimize on the assumption that
@@ -116,7 +116,7 @@ rather than on the underlying platform. For those details that are dependent
 on the platform, on WebAssembly they follow naturally from having 8-bit bytes,
 32-bit and 64-bit two's complement integers, and
 [32-bit and 64-bit IEEE-754-2008-style floating point support]
-(AstSemantics.md#floating-point-operators).
+(Semantics.md#floating-point-operators).
 
 ## Portability of compiled code
 

DynamicLinking.md

@@ -2,8 +2,8 @@
 
 WebAssembly enables load-time and run-time (`dlopen`) dynamic linking in the
 MVP by having multiple [instantiated modules](Modules.md)
-share functions, [linear memories](AstSemantics.md#linear-memory),
-[tables](AstSemantics.md#table) and [constants](AstSemantics.md#constants)
+share functions, [linear memories](Semantics.md#linear-memory),
+[tables](Semantics.md#table) and [constants](Semantics.md#constants)
 using module [imports](Modules.md#imports) and [exports](Modules.md#exports). In
 particular, since all (non-local) state that a module can access can be imported
 and exported and thus shared between separate modules' instances, toolchains

FAQ.md

@@ -310,7 +310,7 @@ syscall in POSIX, WebAssembly unpacks this functionality into multiple
 operators:
 
 * the MVP starts with the ability to grow linear memory via a
-  [`grow_memory`](AstSemantics.md#resizing) operator;
+  [`grow_memory`](Semantics.md#resizing) operator;
 * proposed
   [future features](FutureFeatures.md#finer-grained-control-over-memory) would
   allow the application to change the protection and mappings for pages in the

FutureFeatures.md

@@ -33,7 +33,7 @@ Provide access to safe OS-provided functionality including:
   performing these operators in sequence.
 
 The `addr` and `length` parameters above would be required to be multiples of
-[`page_size`](AstSemantics.md#resizing).
+[`page_size`](Semantics.md#resizing).
 
 The `mprotect` operator would require hardware memory protection to execute
 efficiently and thus may be added as an "optional" feature (requiring a
@@ -51,7 +51,7 @@ can allocate noncontiguous virtual address ranges. See the
 
 Some platforms offer support for memory pages as large as 16GiB, which 
 can improve  the efficiency of memory management in some situations. WebAssembly
-may offer programs the option to specify a larger page size than the [default] (AstSemantics.md#resizing).
+may offer programs the option to specify a larger page size than the [default] (Semantics.md#resizing).
 
 ## More expressive control flow
 
@@ -139,7 +139,7 @@ Useful properties of signature-restricted PTCs:
 
 General-purpose Proper Tail Calls would have no signature restrictions, and
 therefore be more broadly usable than
-[Signature-restricted Proper Tail Calls](AstSemantics.md#signature-restricted-proper-tail-calls),
+[Signature-restricted Proper Tail Calls](Semantics.md#signature-restricted-proper-tail-calls),
 though there would be some different performance characteristics.
 
 ## Asynchronous Signals
@@ -301,7 +301,7 @@ quadruple precision.
 
 WebAssembly floating point conforms IEEE 754-2008 in most respects, but there
 are a few areas that are
-[not yet covered](AstSemantics.md#floating-point-operators).
+[not yet covered](Semantics.md#floating-point-operators).
 
 To support exceptions and alternate rounding modes, one option is to define an
 alternate form for each of `add`, `sub`, `mul`, `div`, `sqrt`, and `fma`. These
@@ -382,7 +382,7 @@ pass was otherwise necessary.
 
 In the MVP, there are no global variables; C/C++ global variables are stored in
 linear memory and thus accessed through normal
-[linear memory operators](AstSemantics.md#linear-memory-operators).
+[linear memory operators](Semantics.md#linear-memory-operators).
 [Dynamic linking](DynamicLinking.md) will add some form of immutable global
 variable analogous to "symbols" in native binaries. In some cases, though,
 it may be useful to have a fully mutable global variable which lives outside
@@ -437,7 +437,7 @@ since opaque, could be implemented as a raw function pointer).
 ## More Table Operators and Types
 
 In the MVP, WebAssembly has limited functionality for operating on 
-[tables](AstSemantics.md#table) and the host-environment can do much more (e.g.,
+[tables](Semantics.md#table) and the host-environment can do much more (e.g.,
 see [JavaScript's `WebAssembly.Table` API](JS.md#webassemblytable-objects)).
 It would be useful to be able to do everything from within WebAssembly so, e.g.,
 it was possible to write a WebAssembly dynamic loader in WebAssembly. As a

GC.md

@@ -87,7 +87,7 @@ signatures. In particular:
   would map to exported [opaque reference types](GC.md#opaque-reference-types);
 * methods of WebIDL interfaces would map to exported functions where the
   receiver was translated into an explicit argument and WebIDL value
-  types were mapped to appropriate [value types](AstSemantics.md#types)
+  types were mapped to appropriate [value types](Semantics.md#types)
   (e.g., [bindTexture](https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.14)
   would translate to `void (WebGLRenderingContextBase, int32, WebGLTexture?)`).
 

JS.md

@@ -15,7 +15,7 @@ as defined below and will be removed at some point in the future.*
 
 ## Traps
 
-Whenever WebAssembly semantics specify a [trap](AstSemantics.md#traps),
+Whenever WebAssembly semantics specify a [trap](Semantics.md#traps),
 a `WebAssembly.RuntimeError` object is thrown. WebAssembly code (currently)
 has no way to catch this exception and thus the exception will necessarily
 propagate to the enclosing non-WebAssembly caller (either the browser or
@@ -342,7 +342,7 @@ call one with the `new` operator.
 
 ## `WebAssembly.Memory` Objects
 
-A `WebAssembly.Memory` object contains a single [linear memory](AstSemantics.md#linear-memory)
+A `WebAssembly.Memory` object contains a single [linear memory](Semantics.md#linear-memory)
 which can be simultaneously referenced by multiple `Instance` objects. Each
 `Memory` object has two internal slots:
  * [[Memory]] : a [`Memory.memory`](https://github.com/WebAssembly/spec/blob/master/ml-proto/spec/memory.mli)
@@ -405,7 +405,7 @@ is thrown.
 Let `d` be [`ToNonWrappingUint32`](#tononwrappinguint32)(`delta`).
 
 Let `ret` be the result of performing a
-[`grow_memory`](AstSemantics.md#resizing) operation given delta `d`.
+[`grow_memory`](Semantics.md#resizing) operation given delta `d`.
 
 If `ret` is `-1`, a `WebAssembly.RuntimeError` is thrown.
 
@@ -429,7 +429,7 @@ is thrown. Otherwise return `M.[[BufferObject]]`.
 
 ## `WebAssembly.Table` Objects
 
-A `WebAssembly.Table` object contains a single [table](AstSemantics.md#table)
+A `WebAssembly.Table` object contains a single [table](Semantics.md#table)
 which can be simultaneously referenced by multiple `Instance` objects. Each
 `Table` object has two internal slots:
  * [[Table]] : a [`Table.table`](https://github.com/WebAssembly/spec/blob/master/ml-proto/spec/table.mli)

MVP.md

@@ -13,7 +13,7 @@ documents:
 * The distributable, loadable and executable unit of code in WebAssembly
   is called a [module](Modules.md).
 * The behavior of WebAssembly code in a module is specified in terms of 
-  [instructions](AstSemantics.md) for a structured stack machine.
+  [instructions](Semantics.md) for a structured stack machine.
 * The WebAssembly binary format, which is designed to be natively decoded by 
   WebAssembly implementations, is specified as a 
   [binary encoding](BinaryEncoding.md) of a module's structure and code.

Modules.md

@@ -31,13 +31,13 @@ various operators and section fields in the module:
 A module can declare a sequence of **imports** which are provided, at
 instantiation time, by the host environment. There are several kinds of imports:
 * **function imports**, which can be called inside the module by the
-  [`call`](AstSemantics.md#calls) operator;
+  [`call`](Semantics.md#calls) operator;
 * **global imports**, which can be accessed inside the module by the
-  [global operators](AstSemantics.md#global-variables);
+  [global operators](Semantics.md#global-variables);
 * **linear memory imports**, which can be accessed inside the module by the
-  [memory operators](AstSemantics.md#linear-memory); and
+  [memory operators](Semantics.md#linear-memory); and
 * **table imports**, which can be accessed inside the module by 
-  [call_indirect](AstSemantics.md#calls) and other
+  [call_indirect](Semantics.md#calls) and other
   table operators in the 
   [future](FutureFeatures.md#more-table-operators-and-types).
 
@@ -73,7 +73,7 @@ maximum length *less-or-equal* than the maximum length declared in the import.
 This ensures that separate compilation can assume: memory accesses below the
 declared initial length are always in-bounds, accesses above the declared
 maximum length are always out-of-bounds and if initial equals maximum, the
-length is fixed. In the MVP, every memory is a [default memory](AstSemantics.md#linear-memory)
+length is fixed. In the MVP, every memory is a [default memory](Semantics.md#linear-memory)
 and thus there may be at most one linear memory import or linear memory
 section.
 
@@ -82,7 +82,7 @@ A *table import* includes the same set of fields defined in the
 length* and optional *maximum length*. As with the linear memory section, the
 host environment must ensure only WebAssembly tables are imported with
 exactly-matching element type, greater-or-equal initial length, and
-less-or-equal maximum length. In the MVP, every table is a [default table](AstSemantics.md#table)
+less-or-equal maximum length. In the MVP, every table is a [default table](Semantics.md#table)
 and thus there may be at most one table import or table section.
 
 Since the WebAssembly spec does not define how import names are interpreted:
@@ -157,7 +157,7 @@ interchangeable with ES6 modules (ignoring
 [GC/Web API](FutureFeatures.md#gc/dom-integration) signature restrictions of the
 WebAssembly MVP) and thus it should be natural to compose a single application
 from both kinds of code. This goal motivates the
-[semantic design](AstSemantics.md#linear-memory) of giving each WebAssembly
+[semantic design](Semantics.md#linear-memory) of giving each WebAssembly
 module its own disjoint linear memory. Otherwise, if all modules shared a single
 linear memory (all modules with the same realm? origin? window?—even the
 scope of "all" is a nuanced question), a single app using multiple
@@ -199,24 +199,24 @@ A module can:
 ## Global section
 
 The *global section* provides an internal definition of zero or more
-[global variables](AstSemantics.md#global-variables).
+[global variables](Semantics.md#global-variables).
 
 Each global variable internal definition declares its *type*
-(a [value type](AstSemantics.md#types)), *mutability* (boolean flag) and
+(a [value type](Semantics.md#types)), *mutability* (boolean flag) and
 *initializer* (an [initializer expression](#initializer-expression)).
 
 ## Linear memory section
 
 The *linear memory section* provides an internal definition of one
-[linear memory](AstSemantics.md#linear-memory). In the MVP, every memory is a
+[linear memory](Semantics.md#linear-memory). In the MVP, every memory is a
 default memory and thus there may be at most one linear memory import or linear
 memory section.
 
-Each linear memory section declares an *initial* [memory size](AstSemantics.md#linear-memory)
-(which may be subsequently increased by [`grow_memory`](AstSemantics.md#resizing)) and an
+Each linear memory section declares an *initial* [memory size](Semantics.md#linear-memory)
+(which may be subsequently increased by [`grow_memory`](Semantics.md#resizing)) and an
 optional *maximum memory size*.
 
-[`grow_memory`](AstSemantics.md#resizing) is guaranteed to fail if attempting to
+[`grow_memory`](Semantics.md#resizing) is guaranteed to fail if attempting to
 grow past the declared maximum. When declared, implementations *should*
 (non-normative) attempt to reserve virtual memory up to the maximum size. While
 failure to allocate the *initial* memory size is a runtime error, failure to
@@ -237,7 +237,7 @@ value (defining the length of the given segment). The `offset` is an
 ## Table section
 
 The *table section* contains zero or more definitions of distinct 
-[tables](AstSemantics.md#table). In the MVP, every table is a 
+[tables](Semantics.md#table). In the MVP, every table is a 
 default table and thus there may be at most one table import or table section.
 
 Each table definition declares an *element type*, *initial length*, and
@@ -294,7 +294,7 @@ function definitions, assigning monotonically-increasing indices based on the
 order of definition in the module (as defined by the [binary encoding](BinaryEncoding.md)).
 
 The function index space is used by:
-* [calls](AstSemantics.md#calls), to identify the callee of a direct call
+* [calls](Semantics.md#calls), to identify the callee of a direct call
 
 ## Global Index Space
 
@@ -303,7 +303,7 @@ global definitions, assigning monotonically-increasing indices based on the
 order of definition in the module (as defined by the [binary encoding](BinaryEncoding.md)).
 
 The global index space is used by:
-* [global variable access operators](AstSemantics.md#global-variables), to
+* [global variable access operators](Semantics.md#global-variables), to
   identify the global variable to read/write
 * [data segments](#data-section), to define the offset of a data segment
   (in linear memory) as the value of a global variable
@@ -347,7 +347,7 @@ expressions.
 In the MVP, to keep things simple while still supporting the basic needs
 of [dynamic linking](DynamicLinking.md), initializer expressions are restricted
 to the following nullary operators:
- * the four [constant operators](AstSemantics.md#constants); and
+ * the four [constant operators](Semantics.md#constants); and
  * `get_global`, where the global index must refer to an immutable import.
 
 In the future, operators like `i32.add` could be added to allow more expressive

Portability.md

@@ -27,7 +27,7 @@ characteristics:
   emulation thereof.
 * Two's complement signed integers in 32 bits and optionally 64 bits.
 * IEEE 754-2008 32-bit and 64-bit floating point, except for
-  [a few exceptions](AstSemantics.md#floating-point-operators).
+  [a few exceptions](Semantics.md#floating-point-operators).
 * Little-endian byte ordering.
 * Memory regions which can be efficiently addressed with 32-bit
   pointers or indices.