See issue innative-sdk#3.

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

Also remove some of the stuff from the bulk memory proposal that really
should be written in the spec ReST files.

I think it's a better name than `set`, especially considering we may have a `table.set` in the future, which will likely set just one value.

It also follows naming of [Array.prototype.fill](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/fill) which has similar behavior.

Also fix some typos I noticed.

This follows the naming discussed in issue
WebAssembly#627.

* [spec] Initial documentation of syntax

Includes the basic structure needed for the proposal, but no validation,
binary, text or execution.

Using `memory.init` or `memory.drop` on an active segment is a validation error, not a trap.

…ly#28)

The current state seems to remove the placeholder table/memory index from the encoding to use it as an active flag.

…mory.init`, `memory.drop`, `table.init`, and `table.drop` identify passive segments; only that they index a valid segment. (WebAssembly#31)

I recently looked into adding support for bulk memory operations into
some Rust tooling in preparation for an overall threading story, and on
reading the overview here I was slightly confused about a few encodings
and some semantics. In the end I'm hopeful that these updates can help
clarify these for future readers! No major functional change is intended
here, only tweaks to wording and clarification of what I believe the
original intent of the instructions were.

Changes made were:

* Fixed a broken `modules.html` link
* Clarified some wording about how the new encoding of data segments
  with a flags field up front is backwards compatible.
* Lifted the style of specifying encodings in `BinaryEncoding.md` to
  replace the current table for the new encoding of a data section. (I
  found this to be a bit more readable, but it should be functionally
  the same!)
* Update `memory.*` instructions (and transitively `table.*`) to all be
  succeeded by an immediate index of which memory/table to operate over.
  This should, in the future, allow initializing/dropping data segments
  with multiple memories in play.
* Updated the chart of instruction binary encodings to explicitly
  specify the following immediates of segments and tables.

This commit fixes WebAssembly#34 by specifying that the flags field (which
indicates if a segment is passive) is a `varuint32` instead of a
`uint8`. It was discovered in WebAssembly#34 that the memory index located at that
position today is a `varuint32`, which can be validly encoded as `0x80
0x00` in addition to `0x00` (in addition to a number of other
encodings). This means that if the first field were repurposed as a
single byte of flags, it would break these existing modules that work
today.

It's not currently known how many modules in the wild actually take
advantage of such an encoding, but it's probably better to be safe than
sorry!

Closes WebAssembly#34

* Update Overview.md for element segments

Passive element segments now include an element type, and have a sequence of expressions instead of function indices.

…able.copy`. (WebAssembly#29)

This would make it simpler to extend those instructions to support multiple memories/tables, and copying between different memories/tables.

The current encoding has a single placeholder zero byte for those instructions, which allows extension to multiple memories/tables, but would require a more complicated encoding to add two immediate indices.

See WebAssembly/reference-types#18, WebAssembly#29, and WebAssembly#36

The order of the `table.init` and `memory.init` immediates should be the index followed by the reserved byte (which is a placeholder for the table or memory index). This matches ordering of immediates in `call_indirect` (type index, followed by table index reserved byte).

`memory.init`, `memory.copy`, `memory.fill`, `table.init`, and `table.copy` should all fail if their ranges are out-of-bounds, even if the count is zero, similar to for active segments. See the discussions here: WebAssembly/design#897, WebAssembly/bulk-memory-operations#11.

Based on the proposal howto:
https://github.com/WebAssembly/proposals/blob/master/howto.md

Decoding 64 as an signed LEB will produce the value -64 = 4294967232.
This change adds tests to ensure that the segment is decoded as 64.

This was fixed in the interpreter in the last PR, but only fixed the
messages in various assertions. This commit adds a new explicit test for
this.

Fixes WebAssembly#142. A mismatched `DataCount` is malformed, not a validation error.

The data/elem index comes before the memory/table index.

See the non-trapping-float-to-int-conversions proposal here:

https://github.com/WebAssembly/nontrapping-float-to-int-conversions

See the sign-extension-ops proposal here:

https://github.com/WebAssembly/sign-extension-ops

This PR is built on top of WebAssembly#1143 (merge nontrapping-float-to-int).

See the multi-value proposal here:

https://github.com/WebAssembly/multi-value

This PR is built on top of the following PRs:

* WebAssembly#1143 (merge nontrapping-float-to-int)
* WebAssembly#1144 (merge sign-extension-ops)

There are already tests for effective address overflow, but those have a
large value baked into the offset. These tests all use `1` as the
immediate offset, and use `-1` for the address on the stack, which may
be compiled differently.

We've recently found a bug in a WebAssembly library we've been working
with where we're mapping WebAssembly to a tree-like IR internally. The
way we parse into this representation, however, has a bug when the
function isn't itself tree-like but rather exibits properties that
exploit a stack machine. For example this isn't so straightforward to
represent in a tree-like fashion:

    (import "" "a" (func $foo))
    (import "" "b" (func $foo (result i32)))
    (func (result i32)
      call $b
      call $b
      call $a
      i32.xor)

The extra `call $a` in the middle is valid `WebAssembly` but needs
special treatment when converting to a more tree-like IR format. I
figured it'd be good to ensure there's a spec test covering this case as
we currently pass the suite of spec tests but still contain this bug!

This also required disambiguating the references to "module", as there are now
two definitions by that name.

Issue WebAssembly/reference-types#69 requires
that `ref.null` instructions include a reference type immediate. This
concept isn't present in the bulk-memory proposal, but the encoding is
(in element segment expressions).

This change updates the binary and text format, but not the syntax. This
is OK for now, since the only reference type allowed here is `funcref`.

…ble (WebAssembly#139)

Fixes WebAssembly#138

…perations into update-to-bulk-mem