Define memmove and memzero operators.

[sunfishcode]

This proposes what I sketched out in #236.

I'm quite open to discussing extensions to these operators to accept e.g. size and alignment hints (size hints may include things like known-multiples or known-ranges when the size isn't constant), but let's do so in a new issue.

Why memzero and not memset? It's simpler while still covering the main use case. On one hand, I'm already a nervous about adding what could be seen as macro-operators to WebAssembly in the first place. And on the other, the ability to paint memory regions with just a single-byte pattern is oddly restrictive. If we're going to add functionality like that, perhaps we should add forms for 32-bit and 64-bit patterns too.

[jfbastien]

• It would be useful to add this under an "intrinsics" or "builtins" section.
• I'd have type signatures.
• I prefer memset over memzero. It's not really more complicated, is as familiar, and is useful.

[sunfishcode]

It would be useful to add this under an "intrinsics" or "builtins" section.

This is a path which I'm specifically nervous about, and am liable to abandon and subsequently oppose the addition of even memmove if I suspect this is where it'll lead. We can always do memmove in a library reasonably well, especially once we get SIMD.

I'd have type signatures.

"Everything is int32", and the future "Everything is int64", are pretty simple (and note that this is nicer with memzero over memset, will the value operand be int64 in the 64-bit pointer version?). Avoiding an explicit type signature declaration encourages us to keep things simple :-).

I prefer memset over memzero. It's not really more complicated, is as familiar, and is useful.

memset might be confusing to some when they pass it an int32 and it ignores part of the value. Or when they figure out that there isn't a version that does use the full 32-bit value. But I'm content to see what the consensus is here.

[jfbastien]

Type signatures are easier to read than English IMO :-)

[sunfishcode]

Important to have in a section of intrinsics or builtins, surely :-).

[titzer]

Is there a strong need to have a distinction between intrinsics and the
more basic AST operations? Engines are required to implement both, and both
have well-defined semantics. One view is that it is merely an
implementation detail if a given AST operation or intrinsic function is
implemented as inline code or a subroutine.

On Wed, Jul 29, 2015 at 5:34 AM, Dan Gohman [email protected]
wrote:

Important to have in a section of intrinsics or builtins, surely :-).

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

[qwertie]

@titzer I've been thinking the same thing. In terms of file format, even control flow could be stored the same way as intrinsics (except maybe ... blocks? Blocks are the only thing coming to mind that really seem to need a variable argument list. There could be a binary operator then, but it's inefficient in case of many statements in a row.)

[sunfishcode]

@titzer I agree, I don't think we need such a distinction.

[jfbastien]

No distinction sounds fine.

I'd still like explicit signatures instead of English. We do provide signatures for AST nodes.

I'd also like memset instead of memzero.

[lukewagner]

For core semantics (sbrk, memset), I've been equating the two (builtins and AST nodes) in my mind as well. I think the only distinction comes when we get to host-dependent builtins.

[sunfishcode]

Closing for now; we can reconsider these operators in the future when we look at other bulk memory operations too.