Skip to content
This repository was archived by the owner on Nov 3, 2021. It is now read-only.

Use blocktype binary encoding for the new typed select instruction #50

Closed
wants to merge 1 commit into from
Closed

Use blocktype binary encoding for the new typed select instruction #50

wants to merge 1 commit into from

Conversation

AndrewScheidecker
Copy link
Contributor

The currently proposed typed select instruction encodes its type immediate as vec valtype. IMO it's better for the typed select instruction to use the blocktype encoding from the multi-value extension. It's fixed length, and involves little additional specification/code to reuse the blocktype encoding.

The caveat is that this repo does not have the generalization of block types added by the multi-value repo, so the new select instruction needs to be restricted to arity 1 at the syntax level instead of in validation, as it is currently proposed. The intent is that when this repo and the multi-value repo are merged, the syntax will be relaxed to allow block types with arity > 1, and the validation/execution of the multi-value select will be specified.

@rossberg
Copy link
Member

rossberg commented Jul 1, 2019

See this comment for the rationale behind the format. I honestly don't know what a block type (as introduced by multi-values) would mean for select, since the instruction does not have independent argument and result types, like blocks have.

@AndrewScheidecker
Copy link
Contributor Author

Sorry, I missed that past discussion. Seems to have been considered and decided already, so I'll close this PR.

I honestly don't know what a block type (as introduced by multi-values) would mean for select, since the instruction does not have independent argument and result types, like blocks have.

I was thinking that it would just be constrained by validation to only accept block types with no parameters. I can see how that is out of place in comparison to how the control structure instructions use the multi-value repo blocktype, though.

rossberg pushed a commit that referenced this pull request Nov 20, 2019
* Clarify trapping semantics
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants