[spec/interpreter/test] Avoid lubs and glbs #43
Conversation
|
For multi-value select, I don't see a reason not to allow it. Without |
| @@ -92,7 +92,7 @@ Reference Instructions | |||
| Parametric Instructions | |||
| ~~~~~~~~~~~~~~~~~~~~~~~ | |||
|
|
|||
| :ref:`Parametric instructions <syntax-instr-parametric>` are represented by single byte codes. | |||
| :ref:`Parametric instructions <syntax-instr-parametric>` are represented by single byte codes, possibly followd by a type annotation. | |||
| \end{array} | ||
|
|
||
| The |DROP| operator simply throws away a single operand. | ||
|
|
||
| The |SELECT| operator selects one of its first two operands based on whether its third operand is zero or not. | ||
| It may be include by a :ref:`value type <syntax-valtype>` determining the type of these operands. If missing, the operands must be of :ref:`numeric type <syntax-numtype>`. |
There was a problem hiding this comment.
s/may be include by/may include/ ?
|
@titzer, okay changed to enable multi-value select in the future. |
|
Do we want the encoding of select to be a vector of types? We could reuse the blocktype encoding instead to save 1 byte in most cases. Though we'd have to also check that the type has 0 results. |
|
@binji, good point. My reasoning for using a vector: (1) the most relevant cases where a blocktype would save a byte (numeric types) are already covered by the plain |
|
I'm having a hard time imagining the use case for multi-reference-value select, much less the need to optimize this case. Also, the need to reuse a condition multiple times seems like a reason for us to go ahead and add |
|
@lukewagner, it's not just multi-reference, it would work for all multi-values. The use case for this is the same as for multi-values in general, e.g., imagine a select on two complex numbers. An argument against this would be that there is no native hardware support for this, though I suppose a compiler could make use of vector types in common cases? |
|
Oh hah, sorry, not sure why I was thinking that the new select was only for ref types; commenting too early in the morning... |
|
@rossberg Yep, those seem like good reasons to me. Having written a few decoders now, I've found it a bit nicer when instruction+immediate has a (more or less) fixed length, but we've already ruined that with |
* Add nullref as an externally specifiable type Spec commit: WebAssembly/reference-types@d4bc208 * Add typed select operator for reference types proposal The reftypes proposal adds a typed select operator to simplify type checking for reference types. The existing select operator is henceforth limited to operate on the original MVP types only. Spec change: WebAssembly/reference-types#43
This addresses #42 by:
selectinstruction (opcode 1C, one after plainselect),Question: given the explicitly typed
select, it would be possible to extend it to multiple values under the multi-value proposal. If we want to keep this option open then its type immediate should be a type vector, not a single type. Opinions?