From b1fa2cb742d31211cc4d24b758497683f1e42089 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Mon, 7 Mar 2016 12:46:08 -0600 Subject: Convert remaining fixed-width integers to varuint32 --- BinaryEncoding.md | 44 +++++++++++++++++++------------------------- 1 file changed, 19 insertions(+), 25 deletions(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 6a104a6..9484d74 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -26,15 +26,9 @@ implementations. # Data types -### int8 -A single-byte signed integer. - ### uint8 A single-byte unsigned integer. -### uint16 -A two-byte little endian unsigned integer. - ### uint32 A four-byte little endian unsigned integer. @@ -120,7 +114,7 @@ A module may contain at most one signatures section. #### Signature entry | Field | Type | Description | | ----- | ----- | ----- | -| param_count | `uint8` | the number of parameters to the function | +| 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 | @@ -139,7 +133,7 @@ A module may contain at most one import table section. #### Import entry | Field | Type | Description | | ----- | ----- | ----- | -| sig_index | `uint16` | signature index of the import | +| sig_index | `varuint32` | signature index of the import | | module_len | `varuint32` | module string length | | module_str | `bytes` | module string of `module_len` bytes | | function_len | `varuint32` | function string length | @@ -188,7 +182,7 @@ This section must be preceded by the [Function Signatures](#function-signatures- #### Export entry | Field | Type | Description | | ----- | ----- | ----- | -| func_index | `uint16` | index into the function table | +| func_index | `varuint32` | index into the function table | | function_len | `varuint32` | function string length | | function_str | `bytes` | function string of `function_len` bytes | @@ -219,9 +213,9 @@ a `data_segment` is: | Field | Type | Description | | ----- | ----- | ----- | -| offset | `uint32` | the offset in linear memory at which to store the data | -| size | `uint32` | the size of the data segment (in bytes) | -| data | `bytes` | a sequence of `size` bytes | +| offset | `varuint32` | the offset in linear memory at which to store the data | +| size | `uint32` | size of `data` (in bytes) | +| data | `bytes` | sequence of `size` bytes | ### Indirect Function Table section @@ -233,7 +227,7 @@ of indexes into the [Function Signatures](#function-signatures-section) section | Field | Type | Description | | ----- | ----- | ----- | | count | `varuint32` | count of entries to follow | -| entries | `uint16*` | repeated indexes into the function table | +| entries | `varuint32*` | repeated indexes into the function table | ### Names section @@ -288,7 +282,7 @@ by the decoder. It can used, for example, to store function names or data segmen | Field | Type | Description | | ----- | ----- | ----- | -| body | `bytes` | contents of this section | +| body | `bytes` | contents of this section | Sections whose ID is unknown to the WebAssembly implementation are ignored. @@ -323,13 +317,13 @@ It is legal to have several entries with the same type. | Name | Opcode | Immediate | 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 = `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 | | `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` | 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 | @@ -338,9 +332,9 @@ The `br_table` operator has an immediate operand which is encoded as follows: | Field | Type | Description | | ---- | ---- | ---- | -| 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 | +| target_count | `varuint32` | number of targets in the target_table | +| target_table | `varuint32*` | target entries that indicate an outer block or loop to which to break | +| default_target | `varuint32` | 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 branches to the block or loop at the given offset within the `target_table`. If the input value is @@ -391,10 +385,10 @@ out of range, `br_table` branches to the default target. The `memory_immediate` type is encoded as follows: -| Name | Type | Present? | Description | -| ---- | ---- | ---- | ---- | -| flags | `uint8` | always | a bitfield where
bit `4` indicates an offset follows
bit `7` indicates natural alignment
other bits are reserved for future use | -| offset | `varuint32` | `flags[4] == 1` | the value of the offset | +| Name | Type | Description | +| ---- | ---- | ---- | +| offset | `varuint32` | the value of the offset | +| alignment | `varuint32` | the value of the alignment | ## Simple operators ([described here](AstSemantics#32-bit-integer-operators)) -- cgit v1.2.3 From 3d1fc545dc6b61150021b93fff91895cb4679e94 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Tue, 8 Mar 2016 12:18:47 -0600 Subject: Update flags/alignment immediate --- BinaryEncoding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 9484d74..6ee15d9 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -387,8 +387,8 @@ The `memory_immediate` type is encoded as follows: | Name | Type | Description | | ---- | ---- | ---- | +| flags | `varuint32` | a bitfield currently only containing the alignment (less-or-equal than natural alignment, specified as a power of 2) for the `log2(access size)` least-significant bits | | offset | `varuint32` | the value of the offset | -| alignment | `varuint32` | the value of the alignment | ## Simple operators ([described here](AstSemantics#32-bit-integer-operators)) -- cgit v1.2.3 From c6e52a487a81edd9ccdd7544bd96c367aff991ba Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Tue, 8 Mar 2016 13:05:13 -0600 Subject: Change br_table branch offsets to uint32 --- BinaryEncoding.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 6ee15d9..03acda4 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -333,8 +333,8 @@ 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 | -| target_table | `varuint32*` | target entries that indicate an outer block or loop to which to break | -| default_target | `varuint32` | an outer block or loop to which to break in the default case | +| 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 branches to the block or loop at the given offset within the `target_table`. If the input value is -- cgit v1.2.3 From 9632db5411c6812b4eb83c1397b1463fae442556 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Tue, 8 Mar 2016 19:13:09 -0600 Subject: Clarify alignment description --- BinaryEncoding.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 03acda4..ad77763 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -387,9 +387,15 @@ The `memory_immediate` type is encoded as follows: | Name | Type | Description | | ---- | ---- | ---- | -| flags | `varuint32` | a bitfield currently only containing the alignment (less-or-equal than natural alignment, specified as a power of 2) for the `log2(access size)` least-significant bits | +| flags | `varuint32` | a bitfield which currently contains the alignment in the least significant bits, encoded as `log2(alignment)` | | offset | `varuint32` | the value of the offset | +As implied by the `log2(alignment)` encoding, the alignment must be a power of 2. +As an additional validation criteria, the alignment must be less or equal to +natural alignment. Thus, for any given memory access op, the bits after the +`log(memory-access-size)` least-significant bits can be used in the future +(e.g., for shared memory ordering requirements). + ## Simple operators ([described here](AstSemantics#32-bit-integer-operators)) | Name | Opcode | Immediate | Description | -- cgit v1.2.3 From 369abe553e96dc2ebbe847f4c6a76f05e5c6ef2d Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Wed, 9 Mar 2016 00:08:51 -0600 Subject: Opcodes should also be LEB128; we're definitely going to end up with >256 after SIMD --- BinaryEncoding.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index ad77763..ca988b7 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -57,12 +57,12 @@ sequence, then followed recursively by any child nodes. * Examples * Given a simple AST node: `I32Add(left: AstNode, right: AstNode)` - * First write the opcode for `I32Add` (uint8) + * First write the opcode for `I32Add` (`varuint32`) * Then recursively write the left and right nodes. * Given a call AST node: `Call(callee_index: uint32_t, args: AstNode[])` - * First write the opcode of `Call` (uint8) - * Then write the (variable-length) integer `callee_index` (varuint32) + * First write the opcode of `Call` (`varuint32`) + * Then write the (variable-length) integer `callee_index` (`varuint32`) * Then recursively write each argument node, where arity is determined by looking up `callee_index` in a table of signatures # Module structure -- cgit v1.2.3 From a3ace6fb6e54ea2a7612d77745c590e4a90c09b7 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Wed, 9 Mar 2016 10:50:52 -0600 Subject: Revert "Opcodes should also be LEB128; we're definitely going to end up with >256 after SIMD" This reverts commit edac92d9e10e5fb3ea8e305236c6d00da05a8d48 --- BinaryEncoding.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index ca988b7..ad77763 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -57,12 +57,12 @@ sequence, then followed recursively by any child nodes. * Examples * Given a simple AST node: `I32Add(left: AstNode, right: AstNode)` - * First write the opcode for `I32Add` (`varuint32`) + * First write the opcode for `I32Add` (uint8) * Then recursively write the left and right nodes. * Given a call AST node: `Call(callee_index: uint32_t, args: AstNode[])` - * First write the opcode of `Call` (`varuint32`) - * Then write the (variable-length) integer `callee_index` (`varuint32`) + * First write the opcode of `Call` (uint8) + * Then write the (variable-length) integer `callee_index` (varuint32) * Then recursively write each argument node, where arity is determined by looking up `callee_index` in a table of signatures # Module structure -- cgit v1.2.3 From 67c28db3a46d639b8385e35daee9e294c0d84acf Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Wed, 9 Mar 2016 13:07:32 -0600 Subject: Add back the varuint32 in data_segment --- BinaryEncoding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index ad77763..efdd36c 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -214,7 +214,7 @@ a `data_segment` is: | Field | Type | Description | | ----- | ----- | ----- | | offset | `varuint32` | the offset in linear memory at which to store the data | -| size | `uint32` | size of `data` (in bytes) | +| size | `varuint32` | size of `data` (in bytes) | | data | `bytes` | sequence of `size` bytes | ### Indirect Function Table section -- cgit v1.2.3