resize_memory, memory_size, page_size: opcodes or intrinsic functions?

[AndrewScheidecker]

Is there a reason for these to being special opcodes vs just being functions imported from some implementation-provided intrinsic module? I think there are three things to trade off here:

• It's simpler in my implementation, and I imagine most others to add an intrinsic function.
• A dedicated opcode is more efficient for encoding frequently used operations.
• It's simpler to dispatch dedicated opcodes if you want to generate machine code that's not just a call.

I think all three of these opcodes (resize_memory, memory_size, and page_size) could all be intrinsic functions with very little effect on size or speed, so I don't think it's worth having dedicated opcodes for these.

[jfbastien]

ASTSemantics isn't very clear on whether they're opcodes or intrinsics! I'd been assuming that they were intrinsics as that seems more natural.

[AndrewScheidecker]

ASTSemantics says "builtin operation", which is a little ambiguous, but to
me means a special type of AST node with a dedicated opcode.

[sunfishcode]

Presently, wasm has no intrinsic functions.

2 of the 3 bullet points in the original post here favor dedicated opcodes, and for the third, it's not clear why intrinsic functions would be easier to implement. And, it keeps the overall system simpler if we don't have multiple kinds of things (operators and intrinsics) that serve the same purpose.

[AndrewScheidecker]

wasm does have intrinsic functions, they're just not called that. stdio.print in the spec interpreter is an example of what I mean by "intrinsic function". It's just a function that's imported from a module defined by the implementation. So a resize_memory intrinsic would look something like this:

(import $resize_memory "wasm_intrinsics" "resize_memory" (param i32))
...
(call_import $resize_memory (const.i32 10000))

It's easier to implement such a function because most consumers of the AST don't need to know anything about it.

It would be more work writing macros if using imports and these are important core operations that macros may well want to be working with. Implementations might even be flagging uses of these function and this will be easier if they are core operations.

[sunfishcode]

stdio.print is a host function, rather than being part of the main wasm spec, and we can have fairly clear criteria for what's a host function and what's not: host functions just do eg. I/O and don't need to interact with core semantics in any special way. resize_memory affects sandboxing, so it is something that many consumers will need to be aware of.

[titzer]

Operations resizing and otherwise manipulating the linear memory are
fundamental to the engine's operation, so I think they make the most sense
as opcodes.

On Mon, Sep 21, 2015 at 6:11 AM, Dan Gohman notifications@github.com
wrote:

stdio.print is a host function, rather than being part of the main wasm
spec, and we can have fairly clear criteria for what's a host function and
what's not: host functions just do eg. I/O and don't need to interact with
core semantics in any special way. resize_memory affects sandboxing, so it
is something that many consumers will need to be aware of.

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

[AndrewScheidecker]

Why does "fundamental to the engine's operation" mean it needs to be an opcode? We'll eventually have things like dlopen, mmap, and create_thread that are "fundamental to the engine's operation", but they don't need to be opcodes any more than resize_memory does. It can work either way, but I think defining another 20 opcodes for such things would be very unwieldy.

I made a branch of the spec interpreter with these implemented as intrinsic functions instead of opcodes: AndrewScheidecker/WebAssembly-spec@74c1cfc

It removes their implementation from the lexer, the parser, the type checker, and the evaluator. Instead, the import matching is extended to call Intrinsics.match_import if the import module is "wasm_intrinsics", and those functions are defined in the spec/intrinsics module. That module is distinct from the host/builtins module to make it clear that they are an integral part of the spec and not something host-specific.

I hope you can see that in this branch adding e.g. a get_external_time function to the Intrinsics module would be pretty simple compared to adding an opcode for it.

[titzer]

On Mon, Sep 21, 2015 at 4:11 PM, Andrew Scheidecker <
notifications@github.com> wrote:

Why does "fundamental to the engine's operation" mean it needs to be an
opcode? We'll eventually have things like dlopen, mmap, and create_thread
that are "fundamental to the engine's operation", but they don't need to be
opcodes any more than resize_memory does. It can work either way, but I
think defining another 20 opcodes for such things would be very unwieldy.

Why exactly would that be unwieldy? Why define a different kind of animal
(i.e. an intrinsic function) that is somehow shaped differently than an
opcode, but is just as mandatory, has a well-defined signature and
well-defined semantics, etc?

I made a branch of the spec interpreter with these implemented as
intrinsic functions instead of opcodes:
AndrewScheidecker/WebAssembly-spec@74c1cfc
AndrewScheidecker/WebAssembly-spec@74c1cfc

It removes their implementation from the lexer, the parser, the type
checker, and the evaluator. Instead, the import matching is extended to
call Intrinsics.match_import if the import module is "wasm_intrinsics",
and those functions are defined in the spec/intrinsics module. That module
is distinct from the host/builtins module to make it clear that they are
an integral part of the spec and not something host-specific.

I hope you can see that in this branch adding e.g. a get_external_time
function to the Intrinsics module would be pretty simple compared to
adding an opcode for it.

I don't see timekeeping and clocks as fundamental to the operation of the
engine in the same was as memory and threads are, but maybe that's just
perspective. In some sense, I'd see clocks and time as optional foreign
functions that don't need to be spec'd. They can be provided by an embedder
of the engine, like printing and IO, and don't really fundamentally alter
the semantics of the state stored in the engine, namely the memory and the
threads running.

I'd propose that operations that cannot be reasonably implemented by the
embedder outside the engine should be considered for opcode status. Along
those lines, altering the size of memory and creating new threads that run
inside the engine seem to fall into consideration for opcode status.

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

[AndrewScheidecker]

Why exactly would that be unwieldy? Why define a different kind of animal
(i.e. an intrinsic function) that is somehow shaped differently than an
opcode, but is just as mandatory, has a well-defined signature and
well-defined semantics, etc?

The advantage is that it uses the machinery already there to declare and call functions defined outside of the WebAssembly module with a verified signature. You don't have to define its syntax or its encoding, just a signature and semantics.

I don't see timekeeping and clocks as fundamental to the operation of the
engine in the same was as memory and threads are, but maybe that's just
perspective. In some sense, I'd see clocks and time as optional foreign
functions that don't need to be spec'd.

It's true that clocks aren't coupled to the operation of the engine, but they're a pretty fundamental component of the execution environment. It would be tragic if WebAssembly didn't standardize them.

I can understand not including I/O in the base standard, but even in that case I think it would be better to define a standard write_debug_output function similar to Windows OutputDebugString or JavaScript console.log.

[titzer]

On Mon, Sep 21, 2015 at 5:29 PM, Andrew Scheidecker <
notifications@github.com> wrote:

Why exactly would that be unwieldy? Why define a different kind of animal
(i.e. an intrinsic function) that is somehow shaped differently than an
opcode, but is just as mandatory, has a well-defined signature and
well-defined semantics, etc?

The advantage is that it uses the machinery already there to declare and
call functions defined outside of the WebAssembly module with a verified
signature. You don't have to define its syntax or its encoding, just a
signature and semantics.

Pick almost any data-only opcode and you could argue the same thing. They
all have a signature in terms of local types. E.g. we discussed for a long
time whether some floating point opcodes like f64_sqrt should be opcodes or
not. There's no reason why would couldn't, e.g. make all the floating point
opcodes into intrinsics.

So what guiding principle do we use to select what's an opcode and what's
an intrinsic function?

I don't see timekeeping and clocks as fundamental to the operation of the
engine in the same was as memory and threads are, but maybe that's just
perspective. In some sense, I'd see clocks and time as optional foreign
functions that don't need to be spec'd.

It's true that clocks aren't coupled to the operation of the engine, but
they're a pretty fundamental component of the execution environment. It
would be tragic if WebAssembly didn't standardize them.

I can understand not including I/O in the base standard, but even in that
case I think it would be better to define a standard write_debug_output
function similar to Windows OutputDebugString or JavaScript console.log.

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

[AndrewScheidecker]

Pick almost any data-only opcode and you could argue the same thing.

It's possible to turn almost anything into calls, but there's a tradeoff:

So what guiding principle do we use to select what's an opcode and what's
an intrinsic function?

I touched on this in my first post, but it's a tradeoff between encoding size and complexity. Opcodes will be more efficient in terms of encoded size and encode/decode speed (to the extent there aren't too many opcodes), and are simpler to match if you're doing something special for them in your code generator or some other AST transform. But I don't think that tradeoff is worthwhile for resize_memory, and maybe not for memory_size and page_size, though that's more questionable.

[jfbastien]

I tend to prefer representing basic capabilities as functions, or rather syscalls, and not as opcodes. I do think we want to have some nice namespacing, and it would be nice if it all looked like it came from the embedder. For reference, NaCl has a few syscalls.

It's easy to express this in a header file, as a function with usual type signatures. I'm not sure how opcodes would be used from developer's code (inline asm?).

[sunfishcode]

The criteria for what's a host function and what's not is can be pretty clear.

What's missing here are criteria for what would distinguish an "intrinsic" from a builtin operation. The binary encoding has an opcode translation table, so there should be no encoding size or encode/decode speed advantage to making things intrinsics instead of opcodes.

It's pretty easy to expose opcodes to developers, even without inline asm.

[kg]

I don't think it makes sense for things like mmap or sqrt or resize_memory to be opcodes. It eats up valuable opcode index space and requires decoders, disassemblers, etc to implement them individually. If we make them functions we're eliminating most of those problems.

What's the advantage to making them opcodes?