Motivation

To support memory64 proposal.

Details

The Memory64 proposal is a phase 3 proposal.

binary-format

• limits encoding changes to have more entries

  limits ::= 0x00 n:u32        ⇒ i32, {min n, max ϵ}, 0
       |  0x01 n:u32 m:u32  ⇒ i32, {min n, max m}, 0
       |  0x02 n:u32        ⇒ i32, {min n, max ϵ}, 1  ;; from threads proposal
       |  0x03 n:u32 m:u32  ⇒ i32, {min n, max m}, 1  ;; from threads proposal
  +    |  0x04 n:u64        ⇒ i64, {min n, max ϵ}, 0
  +    |  0x05 n:u64 m:u64  ⇒ i64, {min n, max m}, 0
  +    |  0x06 n:u64        ⇒ i64, {min n, max ϵ}, 1  ;; from threads proposal
  +    |  0x07 n:u64 m:u64  ⇒ i64, {min n, max m}, 1  ;; from threads proposal

• memory type extended for new limits encoding (we already reuse the limit struct)
• memarg's offset is read as u64

  -memarg ::= a:u32 o:u32
  +memarg ::= a:u32 o:u64

• Memory instances are extended to have 64-bit vectors and a u64 max size
• Memory instructions use the index type instead of i32
  • t.load memarg
  • t.loadN_sx memarg
  • t.store memarg
  • t.storeN_sx memarg
  • memory.size
  • memory.grow
  • memory.fill
  • memory.copy
  • memory.init
• memory.grow has behavior that depends on the index type
• Bounds checking is required to be the same as for 32-bit memories, that is, the index + offset (a u65) of a load or store operation is required to be checked against the current memory size and trap if out of range.
• validating instructions

Appendix

• Memory64: https://github.com/WebAssembly/memory64