Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Simple Decomposable Design #214

Open
RossTate opened this issue Jun 16, 2022 · 0 comments
Open

[Discussion] Simple Decomposable Design #214

RossTate opened this issue Jun 16, 2022 · 0 comments

Comments

@RossTate
Copy link
Contributor

RossTate commented Jun 16, 2022

This post is prompted by WebAssembly/function-references#44 (comment), where it is observed that the current EH design will make it impossible for compilers to pull instructions out into a separate function without necessarily invalidating the original function (meaning that functions cannot be decomposed into smaller functions). Please refer to that comment for more details.

I labeled this is a discussion, not an issue, because it is not an action item. It is merely something for y'all to ponder as you consider how to address issues like the above (if you choose to address them at all).

Wasm Design

Function/block/instruction types are extended to include an optional (throws type*) clause. This clause essentially indicates the function has a secondary non-trapping return path (though engines are free to implement it instead using zero-cost EH techniques like stack marking and stack walking). To clarify: there can only be at most one such clause.

The instruction sequence (catches $label) instr* end jumps to $label whenever any values are "thrown" during the execution of instr*. The throws type of instr* must be a subtype of the label type of $label. That is, it has type [ti*] -> [to*] provided $label has type [t*] and instr* has type [ti*] -> [to*] (throws t*).

An instruction throw n is added, which "throws" the top n instructions on the stack. It has type [t1 ... tn] -> unreachable (throws t1 ... tn). To clarify: there is no event. In fact, this design has no events whatsoever; every throw is always caught by the most immediately enclosing catches, making events unnecessary (and the type system ensures this is sound).

JS API

The JS API for existing function types is left unchanged. In particular, if a JS function is imported as a wasm function whose type has no throws clause, then exceptions thrown by that JS function are modelled as traps.

If a JS function is imported as a wasm function whose type has a throws t* clause, then any exception thrown by the JS function is converted to t*—akin to how JS values are converted to result types—and thrown as a (wasm) exception.

If a wasm function whose type has a throws t* clause is exported as a JS function, then any exception thrown by the wasm function is converted from t*—akin to how JS values are converted from result types—and thrown as a (JS) exception.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant