> "No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST."
From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks.
> "WebAssembly could be interpreted, or could be AOT compiled."
You can do AOT compilation of JS too. The initial benefits of WebAssembly appear to come from in the binary distribution method and in better use of hardware (low-overhead threads, etc...). That said, there's certainly plenty of potential for WebAssembly to leave other restrictions behind.
"I want to play around with what is essentially profile guided optimization, but with runtime type information. So you get a partially specialized (at least as much as the static compilation can give you) implementation, which then records type information at runtime."
Very advanced optimizations. Emscripten doesn't do that (not yet, but LLVM has PGO).
I've done something similar for PHP before. But what you get is code that essentially embeds a dynamic language runtime into your code in the places where the types aren't known. It's less efficient than JIT compilation.
From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks.
> "WebAssembly could be interpreted, or could be AOT compiled."
You can do AOT compilation of JS too. The initial benefits of WebAssembly appear to come from in the binary distribution method and in better use of hardware (low-overhead threads, etc...). That said, there's certainly plenty of potential for WebAssembly to leave other restrictions behind.