Rename {set,move}_memory to mem.{set,copy}

This aligns with current interest in using `mem.` prefix for memory
operations, see WebAssembly/spec#627 and
WebAssembly/threads#62 (comment).

Author: binji

proposals/bulk-memory-operations/Overview.md

@@ -19,7 +19,7 @@ when profiling some WebAssembly benchmarks. Some examples:
 
 ## Prototype
 
-I implemented a prototype implementation of a `move_memory` instruction in v8 which just calls out
+I implemented a prototype implementation of a `mem.copy` instruction in v8 which just calls out
 to v8's [`MemMove` function](https://cs.chromium.org/chromium/src/v8/src/utils.h?l=446). I compared
 this to an implementation [generated by emscripten](https://gist.github.com/binji/c57dc945bba60985439ef8e5b574eee0) and currently used in the Unity demo. This implementation aligns then performs copies using `i32.load` and `i32.store`. I've also included performance achieved by unrolling this loop manually and increasing the size to `i64`.
 
@@ -39,7 +39,7 @@ This is the core loop:
 ```
 
 The code for the benchmark can be found [here](https://gist.github.com/binji/b8e8bc0c0121235d9f1668bc447c7f8c).
-Note that this will not run properly without a WebAssembly implementation of `move_memory`. For my tests, I
+Note that this will not run properly without a WebAssembly implementation of `mem.copy`. For my tests, I
 hacked a version of v8 to replace any exported function called `memcpy` or `memmove` with a new function with
 the following contents:
 
@@ -48,7 +48,7 @@ the following contents:
   get_local $dst
   get_local $src
   get_local $size
-  move_memory
+  mem.copy
   get_local $dst)
 ```
 
@@ -78,7 +78,7 @@ Here are the results on my machine (x86_64, 2.9GHz, L1 32k, L2 256k, L3 256k):
 
 This proposal introduces 2 new instructions:
 
-`move_memory`:
+`mem.copy`:
 
 Copy data from a source memory region to destination region;
 these regions may overlap: the copy is performed as if the source region was 
@@ -91,7 +91,7 @@ The instruction has the signature `[i32 i32 i32] -> []`. The parameters are, in
 - top-1: source address
 - top-0: size of memory region in bytes
 
-`set_memory`: Set all bytes in a memory region to a given byte.
+`mem.set`: Set all bytes in a memory region to a given byte.
 
 The instruction has the signature `[i32 i32 i32] -> []`. The parameters are, in order:
 
@@ -106,25 +106,25 @@ immediate.
 
 ```
 instr ::== ...
-    | move_memory
-    | set_memory
+    | mem.copy
+    | mem.set
 ```
 
 ## Validation
 
-`move_memory`
+`mem.copy`
 
 * The memory `C.mems[0]` must be defined in the context.
 * Then the instruction is valid with type `[i32 i32 i32] -> []`.
 
-`set_memory`
+`mem.set`
 
 * The memory `C.mems[0]` must be defined in the context.
 * Then the instruction is valid with type `[i32 i32 i32] -> []`.
 
 ## Execution
 
-`move_memory`
+`mem.copy`
 
 1. Let `F` be the current frame.
 1. Assert: due to validation, `F.module.memaddrs[0]` exists.
@@ -144,7 +144,7 @@ instr ::== ...
 1. Let `b*` be the byte sequence `mem.data[s:n]`.
 1. Replace the bytes `mem.data[d:n]` with `b*`.
 
-`set_memory`
+`mem.set`
 
 1. Let `F` be the current frame.
 1. Assert: due to validation, `F.module.memaddrs[0]` exists.
@@ -167,8 +167,8 @@ instr ::== ...
 
 ```
 instr ::= ...
-    | 0xC5 0x00 => move_memory
-    | 0xC6 0x00 => set_memory
+    | 0xC5 0x00 => mem.copy
+    | 0xC6 0x00 => mem.set
 ```
 
 Note that this skips `0xC0..0xC4` because those are currently proposed to be used for the
@@ -180,6 +180,6 @@ An immediate byte is included for future extensions. It currently must be zero.
 
 ```
 plaininstr_I ::= ...
-    | `move_memory` => move_memory
-    | `set_memory` => set_memory
+    | `mem.copy` => mem.copy
+    | `mem.set` => mem.set
 ```