wasm_validate_atomic (wasm v0.1.0)

View Source

Types and alignment for the 0xFE opcode space.

Ask it for {Kind, ValueType, Width} for any atomic instruction, where Width is the access in bytes. The interpreter reads the same answer, so the two cannot drift apart.

The read-modify-write family is written out rather than derived from the instruction's name. Parsing the name would be shorter, but this function is consulted for every memory instruction in a module, including the ordinary loads and stores of a module with no atomics in it, and a fallthrough that builds a string per instruction is not something to put on the path that validates and instantiates every module.

Alignment is exact here, not a hint. An ordinary load may declare any alignment up to the natural one and the number is only advice; an atomic access must declare exactly its natural alignment, and a module that declares anything else is invalid rather than merely slow. That is what lets an implementation assume the access does not straddle two words.

Summary

Functions

The shape of an atomic instruction.

Functions

mem_op/1

-spec mem_op(atom()) -> {atom() | {rmw, atom()}, i32 | i64, 1..8} | false.

The shape of an atomic instruction.

Kind is one of load, store, {rmw, Operation}, cmpxchg, wait or notify, which is what decides how many operands come off the stack:

kindoperands, top of stack lastresult
loadaddressthe value
storeaddress, valuenone
rmwaddress, valuethe value that was there
cmpxchgaddress, expected, replacementthe value that was there
waitaddress, expected, timeout (i64)i32: 0 woken, 1 not equal, 2 timed out
notifyaddress, count (i32)i32: how many were woken