Separation into classes? about spec HOT 4 CLOSED

On call vs. call_import, there is an open design issue.

from spec.

FWIW in v8-native, we avoid having a heavyweight class-per-structure and
have a list of all opcodes and their input/output types (i.e. signature).
That is mostly because v8-native doesn't ever really reify the AST, but
decodes bytes directly either to validate or to generate an IR graph.

On Wed, Nov 25, 2015 at 12:59 AM, Dan Gohman [email protected]
wrote:

On call vs. call_import, there is an open design issue
WebAssembly/design#421.

—
Reply to this email directly or view it on GitHub
#194 (comment).

from spec.

FWIW, the nature of the else operand to if is quite different from the ones to br and friends. Conceptually, the else-less if is just a syntactic shorthand. Still, it makes sense to unify the conditionals in an internal AST (that's what the spec does as well).

The arguments to br, return et al are different, though. They stand for 0 or 1 value being passed. In a potential post-MVP extension with multiple return values, these would naturally generalise to n-ary lists. From that perspective, it does not make sense to treat different arities as separate operators, internally or externally.

In general, I'd argue that the factorisation of operators as described by AstSemantics is oriented more towards reflecting the concrete binary format and certain decoding considerations than what you'd likely represent with an actual AST. So it would seem natural to structure things somewhat differently in a real-world AST-based implementation.

from spec.

Thanks for the feedback, everyone. Ok, it sounds like there isn't really a "right" way to do this from the spec's perspective, and specific implementations might make different decisions. Not sure yet what I'll do in binaryen, but I lean towards optimizing the AST for code size.

from spec.