Ben L. Titzer
Ben L. Titzer
If it's a question of "to bytecode or not to bytecode" I think I would prefer that we not have bytecodes that create instances or deal with modules. The reason...
@rossberg: generally, yes, it is good to get a handle on the spawned computation, e.g. to perhaps await it, join it, cancel it, etc.
I generally like reducing the `br` zoo down to a `br_on` and `br_on_not` for the heap types. I didn't digest @askeksa-google's union suggestion fully yet. Is it fully orthogonal to...
To be clear, if we are adding these as new opcodes, we are removing/disabling the old opcodes?
sgtm, as long as this repo continues to represent the consensus on the complete set of bytecodes and their semantics, then that last opcode cleanup will be fairly painless.
If the abstract versions of casts don't pop an RTT value off the stack, and the concrete ones do, I would prefer they be separate instructions.
I think our best chance of making progress on understanding overheads is to have replicable experiments on actual wasm engines. In the above, there isn't enough context (no source code,...
There are just too many confounding variables to compare across systems in a meaningful way. We're at the level where a few machine instructions this or that way makes a...
I was just about to suggest something similar to the hook function, and then I saw it was the second comment. This is the least invasive change to Wasm, but...
> > Make a hook for traps > As @lars-t-hansen points out, this does not compose. As a general rule, there must not be any stateful behaviour modes that are...