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