From 0eeb3414c335fbd4c01f08d257a605e9782a3229 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 22 Oct 2015 10:08:33 -1000 Subject: Rename "opcode" to "operator" Addresses #406. --- BinaryEncoding.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 68785fd..f927631 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -78,14 +78,14 @@ Yes: - The section contents (specific to the section type) * A `definitions` section contains (in this order): - The generic section header - - A table (sorted by offset) containing, for each type which has opcodes: + - A table (sorted by offset) containing, for each type which has operators: + A standardized string literal [type name](AstSemantics.md#expression-types). The index of a type name in this table is referred to as a type ID - + 64-bit offset of its opcode table within the section - - A sequence of opcode tables - - An opcode table contains: - + A sequence of standardized string literal [opcode names](AstSemantics.md), - where order determines opcode index + + 64-bit offset of its operator table within the section + - A sequence of operator tables + - An operator table contains: + + A sequence of standardized string literal [operator names](AstSemantics.md), + where order determines operator index * A `code` section contains (in this order): - The generic section header - A table (sorted by offset) containing, for each function: @@ -110,14 +110,14 @@ Data segments represent initialized data that is loaded directly from the binary * Use a preorder encoding of the AST * Efficient single-pass validation+compilation and polyfill -* The data of a node (if there is any), is written immediately after the opcode and before child nodes - * The opcode statically determines what follows, so no generic metadata is necessary. +* The data of a node (if there is any), is written immediately after the operator and before child nodes + * The operator statically determines what follows, so no generic metadata is necessary. * Examples * Given a simple AST node: `struct I32Add { AstNode *left, *right; }` - * First write the opcode of `I32Add` (1 byte) + * First write the operator of `I32Add` (1 byte) * Then recursively write the left and right nodes. * Given a call AST node: `struct Call { uint32_t callee; vector args; }` - * First write the opcode of `Call` (1 byte) + * First write the operator of `Call` (1 byte) * Then write the (variable-length) integer `Call::callee` (1-5 bytes) * Then recursively write each arg node (arity is determined by looking up `callee` in table of signatures) @@ -129,8 +129,8 @@ or tagging. This raises the question of how to reconcile the efficient encoding backwards-compatibility goals. Specifically, we'd like to avoid the situation where a future version of WebAssembly has features -F1 and F2 and vendor V1 implements F1, assigning the next logical opcode indices to F1's new -opcodes, and V2 implements F2, assigning the same next logical opcode indices to F2's new opcodes +F1 and F2 and vendor V1 implements F1, assigning the next logical operator indices to F1's new +operators, and V2 implements F2, assigning the same next logical operator indices to F2's new operators and now a single binary has ambiguous semantics if it tries to use either F1 or F2. This type of non-linear feature addition is commonplace in JavaScript and Web APIs and is guarded against by having unique names for unique features (and associated [conventions](https://hsivonen.fi/vendor-prefixes/)). @@ -139,14 +139,14 @@ The current proposal is to maintain both the efficiency of indices in the [seria conflict-avoidance practices surrounding string names: * The WebAssembly spec doesn't define any global index spaces * So, as a general rule, no magic numbers in the spec (other than the literal [magic number](https://en.wikipedia.org/wiki/Magic_number_%28programming%29)). - * Instead, a module defines its *own* local index spaces of opcodes by providing tables *of names*. + * Instead, a module defines its *own* local index spaces of operators by providing tables *of names*. * So what the spec *would* define is a set of names and their associated semantics. * To avoid (over time) large index-space declaration sections that are largely the same between modules, finalized versions of standards would define named baseline index spaces that modules could optionally use as a starting point to further refine. * For example, to use all of [the MVP](MVP.md) plus [SIMD](PostMVP.md#fixed-width-simd) the declaration could be "base" - followed by the list of SIMD opcodes used. + followed by the list of SIMD operators used. * This feature would also be most useful for people handwriting the [text format](TextFormat.md). * However, such a version declaration does not establish a global "version" for the module or affect anything outside of the initialization of the index spaces; decoders would -- cgit v1.2.3