From ca754afd593e3af4517023d468136a56848d80e6 Mon Sep 17 00:00:00 2001 From: rossberg-chromium Date: Tue, 8 Mar 2016 15:32:24 +0100 Subject: [PATCH 1/9] Add explicit arities --- BinaryEncoding.md | 41 +++++++++++++++++++++++------------------ 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 09e65f59..9cedfedb 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -317,24 +317,26 @@ It is legal to have several entries with the same type. ## Control flow operators ([described here](AstSemantics.md#control-flow-structures)) -| Name | Opcode | Immediate | Description | +| Name | Opcode | Immediates | Description | | ---- | ---- | ---- | ---- | | `nop` | `0x00` | | no operation | -| `block` | `0x01` | count = `uint8` | a sequence of expressions, the last of which yields a value | -| `loop` | `0x02` | count = `uint8` | a block which can also form control flow loops | +| `block` | `0x01` | count : `uint8` | a sequence of expressions, the last of which yields a value | +| `loop` | `0x02` | count : `uint8` | a block which can also form control flow loops | | `if` | `0x03` | | high-level one-armed if | | `if_else` | `0x04` | | high-level two-armed if | | `select` | `0x05` | | select one of two values based on condition | -| `br` | `0x06` | relative_depth = `uint8` | break that targets a outer nested block | -| `br_if` | `0x07` | relative_depth = `uint8` | conditional break that targets a outer nested block | +| `br` | `0x06` | arity : `varuint32`, relative_depth : `uint8` | break that targets a outer nested block | +| `br_if` | `0x07` | arity : `varuint32`, relative_depth : `uint8` | conditional break that targets a outer nested block | | `br_table` | `0x08` | see below | branch table control flow construct | -| `return` | `0x14` | | return zero or one value from this function | +| `return` | `0x14` | arity : `varuint32` | return zero or one value from this function | | `unreachable` | `0x15` | | trap immediately | +All arities must be either 0 or 1 in the MVP. The `br_table` operator has an immediate operand which is encoded as follows: | Field | Type | Description | | ---- | ---- | ---- | +| arity | `varuint32` | number of transfer arguments (0 or 1) | | target_count | `uint16` | number of targets in the target_table | | target_table | `uint16*` | target entries that indicate an outer block or loop to which to break | | default_target | `uint16` | an outer block or loop to which to break in the default case | @@ -344,19 +346,22 @@ branches to the block or loop at the given offset within the `target_table`. If out of range, `br_table` branches to the default target. ## Basic operators ([described here](AstSemantics.md#constants)) -| Name | Opcode | Immediate | Description | + +| Name | Opcode | Immediates | Description | | ---- | ---- | ---- | ---- | -| `i32.const` | `0x0a` | value = `varint32` | a constant value interpreted as `i32` | -| `i64.const` | `0x0b` | value = `varint64` | a constant value interpreted as `i64` | -| `f64.const` | `0x0c` | value = `uint64` | a constant value interpreted as `f64` | -| `f32.const` | `0x0d` | value = `uint32` | a constant value interpreted as `f32` | -| `get_local` | `0x0e` | local_index = `varuint32` | read a local variable or parameter | -| `set_local` | `0x0f` | local_index = `varuint32` | write a local variable or parameter | -| `load_global` | `0x10` | index = `varuint32` | * nonstandard internal opcode | -| `store_global` | `0x11` | index = `varuint32` | * nonstandard internal opcode | -| `call` | `0x12` | function_index = `varuint32` | call a function by its index | -| `call_indirect` | `0x13` | signature_index = `varuint32` | call a function indirect with an expected signature | -| `call_import` | `0x1f` | import_index = `varuint32` | call an imported function by its index | +| `i32.const` | `0x0a` | value : `varint32` | a constant value interpreted as `i32` | +| `i64.const` | `0x0b` | value : `varint64` | a constant value interpreted as `i64` | +| `f64.const` | `0x0c` | value : `uint64` | a constant value interpreted as `f64` | +| `f32.const` | `0x0d` | value : `uint32` | a constant value interpreted as `f32` | +| `get_local` | `0x0e` | local_index : `varuint32` | read a local variable or parameter | +| `set_local` | `0x0f` | local_index : `varuint32` | write a local variable or parameter | +| `load_global` | `0x10` | index : `varuint32` | * nonstandard internal opcode | +| `store_global` | `0x11` | index : `varuint32` | * nonstandard internal opcode | +| `call` | `0x12` | arity : `varuint32`, function_index : `varuint32` | call a function by its index | +| `call_indirect` | `0x13` | arity : `varuint32`, signature_index : `varuint32` | call a function indirect with an expected signature | +| `call_import` | `0x1f` | arity : `varuint32`, import_index : `varuint32` | call an imported function by its index | + +The arity immediates for the different call opcodes give the number of arguments. ## Memory-related operators ([described here](AstSemantics.md#linear-memory-accesses)) From a15a0495771aa572a84cfc74a71290acc9894c8b Mon Sep 17 00:00:00 2001 From: rossberg-chromium Date: Mon, 18 Apr 2016 12:42:50 +0200 Subject: [PATCH 2/9] Merge pull request #648 from WebAssembly/current_memory Add current_memory operator --- AstSemantics.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/AstSemantics.md b/AstSemantics.md index f1031a83..eaa7507c 100644 --- a/AstSemantics.md +++ b/AstSemantics.md @@ -82,19 +82,20 @@ operators. The main storage of a WebAssembly instance, called the *linear memory*, is a contiguous, byte-addressable range of memory spanning from offset `0` and -extending for `memory_size` bytes which can be dynamically grown by -[`grow_memory`](AstSemantics.md#resizing). The linear memory can be considered +extending up to a varying *memory size*. +This size always is a multiple of the WebAssembly page size, +which is 64KiB on all engines (though large page support may be added in the +[future](FutureFeatures.md#large-page-support)). +The initial state of linear memory is specified by the +[module](Modules.md#linear-memory-section), and it can be dynamically grown by +the [`grow_memory`](AstSemantics.md#resizing) operator. + +The linear memory can be considered to be an untyped array of bytes, and it is unspecified how embedders map this array into their process' own [virtual memory][]. The linear memory is sandboxed; it does not alias the execution engine's internal data structures, the execution stack, local variables, or other process memory. -The initial state of linear memory is specified by the -[module](Modules.md#linear-memory-section). The initial and maximum memory size -are required to be a multiple of the WebAssembly page size, which is 64KiB on -all engines (though large page support may be added in the -[future](FutureFeatures.md#large-page-support)). - [virtual memory]: https://en.wikipedia.org/wiki/Virtual_memory In the MVP, linear memory is not shared between threads of execution. Separate @@ -152,7 +153,7 @@ interpreted as an unsigned byte index. Linear memory operators access the bytes starting at the effective address and extend for the number of bytes implied by the storage size. If any of the -accessed bytes are beyond `memory_size`, the access is considered +accessed bytes are beyond the current memory size, the access is considered *out-of-bounds*. The use of infinite-precision in the effective address computation means that @@ -215,6 +216,10 @@ reserve the space up front or if enabling the reserved memory fails. When there is no maximum memory size declared, `grow_memory` is expected to perform a system allocation which may fail. +The current size of the linear memory can be queried by the following operator: + + * `current_memory` : return the current memory size in units of pages. + As stated [above](AstSemantics.md#linear-memory), linear memory is contiguous, meaning there are no "holes" in the linear address space. After the MVP, there are [future features](FutureFeatures.md#finer-grained-control-over-memory) From 9a7f8bef5617d7ee31c2e9dcc1691e48d4f68f12 Mon Sep 17 00:00:00 2001 From: rossberg-chromium Date: Mon, 18 Apr 2016 18:31:46 +0200 Subject: [PATCH 3/9] Reorder section size field (#639) --- BinaryEncoding.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 86a817b9..a5b46513 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -81,16 +81,18 @@ The module starts with a preamble of two fields: This preamble is followed by a sequence of sections. Each section is identified by an immediate string. Sections whose identity is unknown to the WebAssembly implementation are ignored and this is supported by including the size in bytes -for all sections. The encoding of all sections begins as follows: +for all sections. The encoding of sections is structured as follows: | Field | Type | Description | | ----- | ----- | ----- | -| size | `varuint32` | size of this section in bytes, excluding this size | | id_len | `varuint32` | section identifier string length | | id_str | `bytes` | section identifier string of id_len bytes | +| payload_len | `varuint32` | size of this section in bytes | +| payload_str | `bytes` | content of this section, of length payload_len | Each section is optional and may appear at most once. Known sections (from this list) may not appear out of order. +The content of each section is encoded in its `payload_str`. * [Signatures](#signatures-section) section * [Import Table](#import-table-section) section From 07c90748d7681f8da9396020171875f40589478a Mon Sep 17 00:00:00 2001 From: rossberg-chromium Date: Mon, 18 Apr 2016 18:32:57 +0200 Subject: [PATCH 4/9] Prettify section names (#638) --- BinaryEncoding.md | 85 ++++++++++++++++++++++++----------------------- 1 file changed, 43 insertions(+), 42 deletions(-) diff --git a/BinaryEncoding.md b/BinaryEncoding.md index a5b46513..243e8f79 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -94,42 +94,42 @@ Each section is optional and may appear at most once. Known sections (from this list) may not appear out of order. The content of each section is encoded in its `payload_str`. -* [Signatures](#signatures-section) section -* [Import Table](#import-table-section) section -* [Function Signatures](#function-signatures-section) section -* [Indirect Function Table](#indirect-function-table-section) section +* [Type](#type-section) section +* [Import](#import-section) section +* [Function](#function-section) section +* [Table](#table-section) section * [Memory](#memory-section) section -* [Export Table](#export-table-section) section -* [Start Function](#start-function-section) section -* [Function Bodies](#function-bodies-section) section -* [Data Segments](#data-segments-section) section -* [Names](#names-section) section +* [Export](#export-section) section +* [Start](#start-section) section +* [Code](#code-section) section +* [Data](#data-section) section +* [Name](#name-section) section The end of the last present section must coincide with the last byte of the module. The shortest valid module is 8 bytes (`magic number`, `version`, followed by zero sections). -### Signatures section +### Type section -ID: `signatures` +ID: `type` -The signatures section declares all function signatures that will be used in the module. +The type section declares all function signatures that will be used in the module. | Field | Type | Description | | ----- | ----- | ----- | | count | `varuint32` | count of signature entries to follow | -| entries | `signature_entry*` | repeated signature entries as described below | +| entries | `type_entry*` | repeated type entries as described below | -#### Signature entry +#### Type entry | Field | Type | Description | | ----- | ----- | ----- | | param_count | `varuint32` | the number of parameters to the function | | return_type | `value_type?` | the return type of the function, with `0` indicating no return type | | param_types | `value_type*` | the parameter types of the function | -### Import Table section +### Import section -ID: `import_table` +ID: `import` The import section declares all imports that will be used in the module. @@ -147,29 +147,29 @@ The import section declares all imports that will be used in the module. | function_len | `varuint32` | function string length | | function_str | `bytes` | function string of `function_len` bytes | -### Function Signatures section +### Function section -ID: `function_signatures` +ID: `function` -The Function Signatures section declares the signatures of all functions in the -module. +The function section _declares_ the signatures of all functions in the +module (their definitions appear in the [code section](#code-section)). | Field | Type | Description | | ----- | ----- | ----- | | count | `varuint32` | count of signature indices to follow | -| signatures | `varuint32*` | sequence of indices into the Signature section | +| types | `varuint32*` | sequence of indices into the type section | -### Indirect Function Table section +### Table section -ID: `function_table` +ID: `table` -The indirect function table section defines the module's +The table section defines the module's [indirect function table](AstSemantics.md#calls). | Field | Type | Description | | ----- | ----- | ----- | | count | `varuint32` | count of entries to follow | -| entries | `varuint32*` | repeated indexes into the function table | +| entries | `varuint32*` | repeated indexes into the function section | ### Memory section @@ -184,11 +184,11 @@ associated with the module. | max_mem_pages | `varuint32` | maximum memory size in 64KiB pages | | exported | `uint8` | `1` if the memory is visible outside the module | -### Export Table section +### Export section -ID: `export_table` +ID: `export` -The export table section declares all exports from the module. +The export section declares all exports from the module. | Field | Type | Description | | ----- | ----- | ----- | @@ -202,34 +202,35 @@ The export table section declares all exports from the module. | function_len | `varuint32` | function string length | | function_str | `bytes` | function string of `function_len` bytes | -### Start Function section +### Start section -ID: `start_function` +ID: `start` -The start function section declares the [start function](Modules.md#module-start-function). +The start section declares the [start function](Modules.md#module-start-function). | Field | Type | Description | | ----- | ----- | ----- | | index | `varuint32` | start function index | -### Function Bodies section +### Code section -ID: `function_bodies` +ID: `code` -The Function Bodies section assigns a body to every function in the module. -The count of function signatures and function bodies must be the same and the `i`th -signature corresponds to the `i`th function body. +The code section assigns a body to every function in the module. +The count of function declared in the [function section](#function-section) +and function bodies defined in this section must be the same and the `i`th +declaration corresponds to the `i`th function body. | Field | Type | Description | | ----- | ----- | ----- | ----- | | count | `varuint32` | count of function bodies to follow | | bodies | `function_body*` | sequence of [Function Bodies](#function-bodies) | -### Data Segments section +### Data section -ID: `data_segments` +ID: `data` -The data segments section declares the initialized data that should be loaded +The data section declares the initialized data that should be loaded into the linear memory. | Field | Type | Description | @@ -245,9 +246,9 @@ a `data_segment` is: | size | `varuint32` | size of `data` (in bytes) | | data | `bytes` | sequence of `size` bytes | -### Names section +### Name section -ID: `names` +ID: `name` The names section does not change execution semantics and a validation error in this section does not cause validation for the whole module to fail and is @@ -261,7 +262,7 @@ and locals in the [text format](TextFormat.md). | count | `varuint32` | count of entries to follow | | entries | `function_names*` | sequence of names | -The sequence of `function_name` assigns names to the corresponding +The sequence of `function_names` assigns names to the corresponding function index. The count may be greater or less than the actual number of functions. From 54da3d5c19b18d19ccb12af5dda00edb71859759 Mon Sep 17 00:00:00 2001 From: rossberg-chromium Date: Tue, 19 Apr 2016 15:46:36 +0200 Subject: [PATCH 5/9] Extensible encoding of function signatures (#640) * Prettify section names * Restructure encoding of function signatures * Revert "[Binary 11] Update the version number to 0xB." * Leave index space for growing the number of base types * Comments addressed * clarify how export/import names convert to JS strings (#569) (#573) * When embedded in the web, clarify how export/import names convert to JS strings (#569) * Fixes suggested by @jf * Address more feedback Added a link to http://monsur.hossa.in/2012/07/20/utf-8-in-javascript.html. Simplified the decoding algorithm thanks to Luke's feedback. * Access to proprietary APIs apart from HTML5 (#656) * comments --- BinaryEncoding.md | 19 +++++++++++++------ FAQ.md | 9 +++++++++ Web.md | 29 +++++++++++++++++++++++++++++ 3 files changed, 51 insertions(+), 6 deletions(-) diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 243e8f79..efb1df2e 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -35,6 +35,9 @@ A four-byte little endian unsigned integer. ### varint32 A [Signed LEB128](https://en.wikipedia.org/wiki/LEB128#Signed_LEB128) variable-length integer, limited to int32 values. +### varuint1 +A [LEB128](https://en.wikipedia.org/wiki/LEB128) variable-length integer, limited to the values 0 or 1. `varuint1` values may contain leading zeros. (This type is mainly used for compatibility with potential future extensions.) + ### varuint32 A [LEB128](https://en.wikipedia.org/wiki/LEB128) variable-length integer, limited to uint32 values. `varuint32` values may contain leading zeros. @@ -75,8 +78,8 @@ The module starts with a preamble of two fields: | Field | Type | Description | | ----- | ----- | ----- | -| magic number | `uint32` | Magic number `0x6d736100` == `'\0asm'`. | -| version | `uint32` | Version number `11` == `0x0b`. The version for MVP will be reset to `1`. | +| magic number | `uint32` | Magic number `0x6d736100` (i.e., '\0asm') | +| version | `uint32` | Version number, currently 10. The version for MVP will be reset to 1. | This preamble is followed by a sequence of sections. Each section is identified by an immediate string. Sections whose identity is unknown to the WebAssembly @@ -117,15 +120,19 @@ The type section declares all function signatures that will be used in the modul | Field | Type | Description | | ----- | ----- | ----- | -| count | `varuint32` | count of signature entries to follow | +| count | `varuint32` | count of type entries to follow | | entries | `type_entry*` | repeated type entries as described below | #### Type entry | Field | Type | Description | | ----- | ----- | ----- | +| form | `uint8` | `0x40`, indicating a function type | | param_count | `varuint32` | the number of parameters to the function | -| return_type | `value_type?` | the return type of the function, with `0` indicating no return type | | param_types | `value_type*` | the parameter types of the function | +| return_count | `varuint1` | the number of results from the function | +| return_type | `value_type?` | the result type of the function (if return_count is 1) | + +(Note: In the future, this section may contain other forms of type entries as well, which can be distinguished by the `form` field.) ### Import section @@ -216,7 +223,7 @@ The start section declares the [start function](Modules.md#module-start-function ID: `code` -The code section assigns a body to every function in the module. +The code section contains a body for every function in the module. The count of function declared in the [function section](#function-section) and function bodies defined in this section must be the same and the `i`th declaration corresponds to the `i`th function body. @@ -230,7 +237,7 @@ declaration corresponds to the `i`th function body. ID: `data` -The data section declares the initialized data that should be loaded +The data section declares the initialized data that is loaded into the linear memory. | Field | Type | Description | diff --git a/FAQ.md b/FAQ.md index d61f5f1e..901b2744 100644 --- a/FAQ.md +++ b/FAQ.md @@ -389,3 +389,12 @@ those that motivated the development of the Even Knuth found it worthwhile to give us his opinion on this issue at point, [a flame about 64-bit pointers](http://www-cs-faculty.stanford.edu/~uno/news08.html). + +## Will I be able to access proprietary platform APIs (e.g. Android / iOS)? + +Yes but it will depend on the _WebAssembly embedder_. Inside a browser you'll +get access to the same HTML5 and other browser-specific APIs which are also +accessible through regular JavaScript. However, if a wasm VM is provided as an +[“app execution platform”](NonWeb.md) by a specific vendor, it might provide +access to [proprietary platform-specific APIs](Portability.md#api) of e.g. +Android / iOS. diff --git a/Web.md b/Web.md index 3582c444..d9345d7d 100644 --- a/Web.md +++ b/Web.md @@ -28,6 +28,35 @@ WebAssembly's [modules](Modules.md) allow for natural [integration with the ES6 module system](Modules.md#integration-with-es6-modules) and allow synchronous calling to and from JavaScript. +### Function Names + +A WebAssembly module imports and exports functions. WebAssembly names functions +using arbitrary-length byte sequences. Any 8-bit values are permitted in a +WebAssembly name, including the null byte and byte sequences that don't +correspond to any Unicode code point regardless of encoding. The most natural +Web representation of a mapping of function names to functions is a JS object +in which each function is a property. Property names in JS are UTF-16 encoded +strings. A WebAssembly module may fail validation on the Web if it imports or +exports functions whose names do not transcode cleanly to UTF-16 according to +the following conversion algorithm, assuming that the WebAssembly name is in a +`Uint8Array` called `array`: + +``` +function convertToJSString(array) +{ + var string = ""; + for (var i = 0; i < array.length; ++i) + string += String.fromCharCode(array[i]); + return decodeURIComponent(escape(string)); +} +``` + +This performs the UTF8 decoding (`decodeURIComponent(unescape(string))`) using +a [common JS idiom](http://monsur.hossa.in/2012/07/20/utf-8-in-javascript.html). +Transcoding failure is detected by `decodeURIComponent`, which may throw +`URIError`. If it does, the WebAssembly module will not validate. This validation +rule is only mandatory for Web embedding. + ## Aliasing linear memory from JS If [allowed by the module](Modules.md#linear-memory-section), JavaScript can From d18e5fd669ce3c8c504065974ce9fe698d32f800 Mon Sep 17 00:00:00 2001 From: titzer Date: Thu, 21 Apr 2016 15:40:52 +0200 Subject: [PATCH 6/9] Merge pull request #641 from WebAssembly/postorder_opcodes Postorder opcodes --- BinaryEncoding.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/BinaryEncoding.md b/BinaryEncoding.md index efb1df2e..e8c74d59 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -324,18 +324,20 @@ It is legal to have several entries with the same type. | Name | Opcode | Immediate | Description | | ---- | ---- | ---- | ---- | | `nop` | `0x00` | | no operation | -| `block` | `0x01` | count = `varuint32` | a sequence of expressions, the last of which yields a value | -| `loop` | `0x02` | count = `varuint32` | a block which can also form control flow loops | -| `if` | `0x03` | | high-level one-armed if | -| `if_else` | `0x04` | | high-level two-armed if | +| `block` | `0x01` | | begin a sequence of expressions, the last of which yields a value | +| `loop` | `0x02` | | begin a block which can also form control flow loops | +| `if` | `0x03` | | begin if expression | +| `else` | `0x04` | | begin else expression of if | | `select` | `0x05` | | select one of two values based on condition | | `br` | `0x06` | relative_depth = `varuint32` | break that targets a outer nested block | | `br_if` | `0x07` | relative_depth = `varuint32` | conditional break that targets a outer nested block | | `br_table` | `0x08` | see below | branch table control flow construct | -| `return` | `0x14` | | return zero or one value from this function | -| `unreachable` | `0x15` | | trap immediately | +| `return` | `0x09` | | return zero or one value from this function | +| `unreachable` | `0x0a` | | trap immediately | +| `end` | `0x0f` | | end a block, loop, or if | The `br_table` operator has an immediate operand which is encoded as follows: +Note that there is no explicit `if_else` opcode, as the else clause is encoded with the `else` bytecode. | Field | Type | Description | | ---- | ---- | ---- | @@ -350,15 +352,15 @@ out of range, `br_table` branches to the default target. ## Basic operators ([described here](AstSemantics.md#constants)) | Name | Opcode | Immediate | Description | | ---- | ---- | ---- | ---- | -| `i32.const` | `0x0a` | value = `varint32` | a constant value interpreted as `i32` | -| `i64.const` | `0x0b` | value = `varint64` | a constant value interpreted as `i64` | -| `f64.const` | `0x0c` | value = `uint64` | a constant value interpreted as `f64` | -| `f32.const` | `0x0d` | value = `uint32` | a constant value interpreted as `f32` | -| `get_local` | `0x0e` | local_index = `varuint32` | read a local variable or parameter | -| `set_local` | `0x0f` | local_index = `varuint32` | write a local variable or parameter | -| `call` | `0x12` | function_index = `varuint32` | call a function by its index | -| `call_indirect` | `0x13` | signature_index = `varuint32` | call a function indirect with an expected signature | -| `call_import` | `0x1f` | import_index = `varuint32` | call an imported function by its index | +| `i32.const` | `0x10` | value = `varint32` | a constant value interpreted as `i32` | +| `i64.const` | `0x11` | value = `varint64` | a constant value interpreted as `i64` | +| `f64.const` | `0x12` | value = `uint64` | a constant value interpreted as `f64` | +| `f32.const` | `0x13` | value = `uint32` | a constant value interpreted as `f32` | +| `get_local` | `0x14` | local_index = `varuint32` | read a local variable or parameter | +| `set_local` | `0x15` | local_index = `varuint32` | write a local variable or parameter | +| `call` | `0x16` | function_index = `varuint32` | call a function by its index | +| `call_indirect` | `0x17` | signature_index = `varuint32` | call a function indirect with an expected signature | +| `call_import` | `0x18` | import_index = `varuint32` | call an imported function by its index | ## Memory-related operators ([described here](AstSemantics.md#linear-memory-accesses)) From 7d9d0beb19ffb35ef417d84b16594a1122942521 Mon Sep 17 00:00:00 2001 From: Alon Zakai Date: Fri, 22 Apr 2016 09:00:47 -0700 Subject: [PATCH 7/9] fix some text that seems to be in the wrong order (#670) --- BinaryEncoding.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/BinaryEncoding.md b/BinaryEncoding.md index e8c74d59..d72f7c73 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -336,9 +336,10 @@ It is legal to have several entries with the same type. | `unreachable` | `0x0a` | | trap immediately | | `end` | `0x0f` | | end a block, loop, or if | -The `br_table` operator has an immediate operand which is encoded as follows: Note that there is no explicit `if_else` opcode, as the else clause is encoded with the `else` bytecode. +The `br_table` operator has an immediate operand which is encoded as follows: + | Field | Type | Description | | ---- | ---- | ---- | | target_count | `varuint32` | number of targets in the target_table | From f28dd7ed230907aa61f772b9ccce9097ba6520f6 Mon Sep 17 00:00:00 2001 From: rossberg-chromium Date: Mon, 25 Apr 2016 20:20:20 +0200 Subject: [PATCH 8/9] Clarify that br_table has a branch argument (#664) --- BinaryEncoding.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/BinaryEncoding.md b/BinaryEncoding.md index d72f7c73..2b41bdc1 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -329,8 +329,8 @@ It is legal to have several entries with the same type. | `if` | `0x03` | | begin if expression | | `else` | `0x04` | | begin else expression of if | | `select` | `0x05` | | select one of two values based on condition | -| `br` | `0x06` | relative_depth = `varuint32` | break that targets a outer nested block | -| `br_if` | `0x07` | relative_depth = `varuint32` | conditional break that targets a outer nested block | +| `br` | `0x06` | relative_depth = `varuint32` | break that targets an outer nested block | +| `br_if` | `0x07` | relative_depth = `varuint32` | conditional break that targets an outer nested block | | `br_table` | `0x08` | see below | branch table control flow construct | | `return` | `0x09` | | return zero or one value from this function | | `unreachable` | `0x0a` | | trap immediately | @@ -346,7 +346,8 @@ The `br_table` operator has an immediate operand which is encoded as follows: | target_table | `uint32*` | target entries that indicate an outer block or loop to which to break | | default_target | `uint32` | an outer block or loop to which to break in the default case | -The `br_table` operator implements an indirect branch. It accepts one `i32` expression as input and +The `br_table` operator implements an indirect branch. It accepts an optional value argument +(like other branches) and an additional `i32` expression as input, and 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. From e2402c834383ac39f490cbb922aa5de8e48a7d31 Mon Sep 17 00:00:00 2001 From: Andreas Rossberg Date: Tue, 26 Apr 2016 18:41:52 +0200 Subject: [PATCH 9/9] Rename --- BinaryEncoding.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 3bd40af1..f3436a2f 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -329,16 +329,16 @@ It is legal to have several entries with the same type. | `if` | `0x03` | | begin if expression | | `else` | `0x04` | | begin else expression of if | | `select` | `0x05` | | select one of two values based on condition | -| `br` | `0x06` | arity : `varuint1`, relative_depth : `varuint32` | break that targets an outer nested block | -| `br_if` | `0x07` | arity : `varuint1`, relative_depth : `varuint32` | conditional break that targets an outer nested block | +| `br` | `0x06` | argument_count : `varuint1`, relative_depth : `varuint32` | break that targets an outer nested block | +| `br_if` | `0x07` | argument_count : `varuint1`, relative_depth : `varuint32` | conditional break that targets an outer nested block | | `br_table` | `0x08` | see below | branch table control flow construct | -| `return` | `0x09` | arity : `varuint1` | return zero or one value from this function | +| `return` | `0x09` | argument_count : `varuint1` | return zero or one value from this function | | `unreachable` | `0x0a` | | trap immediately | | `end` | `0x0f` | | end a block, loop, or if | Note that there is no explicit `if_else` opcode, as the else clause is encoded with the `else` bytecode. -The arities following the break and return operators specify how many preceding expressions are taken as arguments; in the MVP, all these arities must be either 0 or 1. +The counts following the break and return operators specify how many preceding operands are taken as transfer arguments; in the MVP, all these values must be either 0 or 1. The `br_table` operator has an immediate operand which is encoded as follows: @@ -364,11 +364,11 @@ out of range, `br_table` branches to the default target. | `f32.const` | `0x13` | value : `uint32` | a constant value interpreted as `f32` | | `get_local` | `0x14` | local_index : `varuint32` | read a local variable or parameter | | `set_local` | `0x15` | local_index : `varuint32` | write a local variable or parameter | -| `call` | `0x16` | arity : `varuint1`, function_index : `varuint32` | call a function by its index | -| `call_indirect` | `0x17` | arity : `varuint1`, type_index : `varuint32` | call a function indirect with an expected signature | -| `call_import` | `0x18` | arity : `varuint1`, import_index : `varuint32` | call an imported function by its index | +| `call` | `0x16` | argument_count : `varuint1`, function_index : `varuint32` | call a function by its index | +| `call_indirect` | `0x17` | argument_count : `varuint1`, type_index : `varuint32` | call a function indirect with an expected signature | +| `call_import` | `0x18` | argument_count : `varuint1`, import_index : `varuint32` | call an imported function by its index | -The arity immediates for the different call opcodes specify the number of preceding expressions taken as arguments. +The counts following the different call opcodes specify the number of preceding operands taken as arguments. ## Memory-related operators ([described here](AstSemantics.md#linear-memory-accesses))