New interpreter (#1330)

It's modeled closely on the wasm-c-api. All runtime objects are
garbage-collected. The GC'd objects are subclasses of `Object` and all
stored in the `Store`. GC roots can be created using a RefPtr<T> struct.

The `Module` stores no runtime objects, only description structs (named
`*Desc`, e.g. `FuncDesc`). Instantiation takes these descriptors and
turns them into runtime objects (e.g. `FuncDesc` is used to create a
`Func`). Only import-matching occurs during instantiation; all other
validation is assumed to have occurred during Module compilation.

As with the previous interpreter, the wasm instructions are not executed
directly, and instead compiled to an instruction stream that is easier
to interpret (e.g. all branches become gotos). It's still a stack
machine, though.

The previous interpreter would always compile and instantiate in one
step, which means that it was always known whether an imported function
is a host function or wasm function. As a result, calls between modules
that stayed in wasm could be very cheap (just update PC). Now that the
module is compiled before instantiation, an imported function call
always has to check first, which may be a slight performance hit.

One major difference to the structure of the interpreter is that
floating-point values are passed directly, instead of using their
equivalent bit pattern. This is more convenient in general, but requires
annotating all functions with WABT_VECTORCALL so Visual Studio x86 works
properly (otherwise floats are passed in the x87 FP stack).

Instruction stream decoding/tracing/disassembling is now all handled in
the `Istream` class. This reduces a lot of duplication between the
three, which makes the logging-all-opcodes and tracing-all-opcodes less
valuable, so I've removed them.

Here are the changes to files:

    binary-reader-metadata.{h,cc} -> [removed]
    interp-{disassemble.trace}.cc -> istream.{h,cc}

There are new helper files:

    interp-util.{h,cc}: Primarily print debugging functions
    interp-math.h: Templates used for handling wasm math

1 files changed, 5 insertions, 5 deletions

diff --git a/test/interp/atomic-rmw-and.txt b/test/interp/atomic-rmw-and.txt
index 3e5b1117..d4d9f610 100644
--- a/test/interp/atomic-rmw-and.txt
+++ b/test/interp/atomic-rmw-and.txt
@@ -102,9 +102,9 @@ i64.atomic.rmw32.and_u-result() => i64:1410065408
 i64.atomic.rmw32.and_u-memory() => i64:1024
 i64.atomic.rmw.and-result() => i64:10000000000
 i64.atomic.rmw.and-memory() => i64:1024
-bad_align-i32.atomic.rmw16.and_u() => error: atomic memory access is unaligned
-bad_align-i32.atomic.rmw.and() => error: atomic memory access is unaligned
-bad_align-i64.atomic.rmw16.and_u() => error: atomic memory access is unaligned
-bad_align-i64.atomic.rmw32.and_u() => error: atomic memory access is unaligned
-bad_align-i64.atomic.rmw.and() => error: atomic memory access is unaligned
+bad_align-i32.atomic.rmw16.and_u() => error: invalid atomic access at 1+0
+bad_align-i32.atomic.rmw.and() => error: invalid atomic access at 2+0
+bad_align-i64.atomic.rmw16.and_u() => error: invalid atomic access at 1+0
+bad_align-i64.atomic.rmw32.and_u() => error: invalid atomic access at 2+0
+bad_align-i64.atomic.rmw.and() => error: invalid atomic access at 4+0
 ;;; STDOUT ;;)