Specify the immediate parameters of table.copy

[gahaas]

At the moment this proposal does not specify the semantics of the immediate operands the table.copy instruction, especially which of the two parameters is destination, and which one is source.
Unfortunately there are already contradicting implementations in Firefox/LLVM/V8/WAVM, so we should close this gap in the Spec quickly.

In V8 I implemented table-copy as table.copy dst src, i.e. destination before source, because this matches the C++ memcpy(dst, src, count) signature. According to my reading of the spec, also non-immediate parameters of table.copy are interpreted destination before source.
However Java's arraycopy function does it different though, source before destination.

[rossberg]

It should of course be analogous to memory.copy, i.e., destination before source. This proposal plus the reftypes one do that consistently for all bulk instructions, as per their spec draft.

I don't see how an implementation can implement it differently and pass the test suite?

[gahaas]

I'm talking of the immediate parameters that specify the destination and source table, not of the stack parameters that specify the destination and source index. The immediate parameters are only spec'ed as 0x00 0x00 here. The reftypes proposal does not have a memory.copy or table.copy instruction.

[rossberg]

Ah, I see. But still, the same applies to memory.copy. Strictly speaking, in both cases, the interpretation only matters in conjunction with the respective addition of multiple memories (multi-memory proposal) and multiple tables (reference-types proposal).

I would argue, though, that dst index should come before src index, because the order shouldn't be different from dynamic operands.

Meta comment: We generally have a few open process questions regarding how to deal with things that lie in the intersection of two parallel proposals. In particular, where to include spec text, how to write tests, and who owns that work. It would be better if we established dependency orderings in such cases. We messed that up completely with the bulk vs reftypes proposals, which now mutually depend on each other, at least as far as the spec text is concerned.

[AndrewScheidecker]

FWIW, the informal text for this proposal does define it as source before destination: https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md#instruction-encoding

We could also formally specify those immediates (both binary and text formats), and rely on validation to enforce that they are zero in the absence of the multi-memory and reference-types proposal.

I would argue, though, that dst index should come before src index, because the order shouldn't be different from dynamic operands.

I agree that it should match the dynamic operands. It seems like it's ok to change it now, since nobody enables both bulk-memory-operations and reference-types by default, but the clock is ticking on that.

Meta comment: We generally have a few open process questions regarding how to deal with things that lie in the intersection of two parallel proposals. In particular, where to include spec text, how to write tests, and who owns that work. It would be better if we established dependency orderings in such cases. We messed that up completely with the bulk vs reftypes proposals, which now mutually depend on each other, at least as far as the spec text is concerned.

Perhaps once a proposal reaches stage 3, it should be merged into the spec repo. That would shake out a lot of the interactions between different proposals that implementations are likely to encounter.

[rossberg]

@AndrewScheidecker, ha, touche. I searched for it but couldn't find it either. I took the liberty to change the overview for @binji in #118.

Perhaps once a proposal reaches stage 3, it should be merged into the spec repo.

Not sure that solves the problem when some of the parallel proposals in question are all in stage 3 already. We'd need to decide who goes first, which is equivalent to defining a dependency order (and makes the champion of the second own the work).