If you want to obtain a "C" pseudocode, you can give a wasm file to wasm2c .
You can re-obtain a WebAssembly folded-expression text format using wasm2wat .
You can obtain a call-graph from a WebAssembly module by generating the wat representation using wasm2wat and pasting it into main.wat on https://webassembly.studio/ (-> Empty Wat Project). Then save and build; right click the new main.wasm and select "Generate Call Graph."
That said, check out this encrypted and anonymous "pastebin" I built  with the crypto being written in Rust and bindings generated using wasm-bindgen . It surprisingly hard to debug when optimized using wasm-opt .
 Part of WebAssembly Binary Toolkit: https://github.com/WebAssembly/wabt
 Source code on Github: https://github.com/psychonautwiki/impis/blob/master/core/src... — Demo paste: https://imp.is/n/7NFsfEiCjkFBVgC6A4JS6GyqN7puN5Sg7ed11m8VrtT...
 Part of Binaryen: https://github.com/WebAssembly/binaryen
Am I the only one who feels like it's the end of the web as we knew it in the 90s and 00s, where you could open any web page, understand how it works and learn from it ?
I hope that we'll come around to the idea that this two-decades long fascination with abusing the hell out of web technology was a fever dream, and go on to build something better on more substantial foundations.
I'm probably going to be disappointed...
My understanding (maybe wrong) was that this was going to be available in the browser.
In order to run the code in the browser, the code will have to be compiled to the binary format.
So where WAT comes in is your methods for producing WASM files now become one of the following:
Source in <otherlang> -> WAT -> WASM
Source in <otherlang> -> WASM
WAT -> WASM
So the human-readable WAT can either be used as a compile target for another language, which can easily be compiled into WASM, or you can write the WAT manually and compile it. Alternatively other languages might be able to compile directly to the binary format, skipping WAT representation entirely.
The translation between WAT and the binary format is lossless, so there's no advantage of producing WAT as an intermediate step.
It's also just as easy to get WASM from WAT as it is WAT from WASM. I don't know of any languages that compile to WAT and then compile to WASM; as far as I know 100% of languages compile directly to WASM.
Web browsers will/already show wasm disassembly when opened in the browser tools. A file can contain label metadata which makes it very readable.
Also, the paper has Emscripten-specific reverse engineering details (such as locations in the mem for where stack starts vs where heap starts) that don't apply to many other WASM compilers.
+003Fh: if $3
+0041h: br $2 (---> break out of $2 (BLOCK))
+0044h: get_local $12
It's kind of like a "comefrom" opcode, a target that other opcodes jump to (or after)!
The opcode allows the virtual machine interpreter to recurse on itself; when it hits the end, the dispatch loop executes return to bail out to the higher level of recursion. Thus end is also useful for exiting the top-level invocation of the VM. It is required, in fact; if the end instruction is not present, the interpreter will keep marching through memory past the end of the routine. No wasteful check is needed whether the instruction pointer is past the code block.
my end instruction also specifies a result value (because the machine is register based; there is no top-of-stack implicit value). This becomes the return value of a procedure when the final end is executed. The block instruction also uses it. When a (block ...) is compiled, the return value of the ordinary block termination is specified in the end instruction at the end of the block. Control returns to the block instruction which receives that value.
end has something in common with the x86 ret instruction and its ilk. It's not so much an exotic "come from" as an ordinary "return".