Rename "opcode" to "operator"

Addresses #406.

1 files changed, 14 insertions, 14 deletions

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<AstNode*> 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