we (web engine): Experimental web browser project to understand the limits of Claude
2
fork

Configure Feed

Select the types of activity you want to include in your feed.

WebAssembly runtime: memories, tables, globals, and instances #222

open opened by pierrelf.com

Implement the runtime data structures that back instantiated WebAssembly modules. Depends on parser and validator issues. No execution yet — those structures must be in place so the interpreter and JS API can be layered on cleanly.

Scope:

  • Memory: linear byte buffer with page-aligned (64 KiB) min/max limits, grow() with copy-on-grow, bounds-checked load/store helpers for every numeric type and alignment, little-endian access only.
  • Table: vector of reference values (funcref / externref); bounds-checked get/set; grow() with default fill; init from element segments.
  • Global: typed value cell with mutability flag; get/set guarded by mutability.
  • Function instance: closure over module instance, type, locals layout, and bytecode body; host functions wrap a Rust callable invoked by the interpreter and JS API bindings.
  • Module instance: indirection layer mapping local function/table/memory/global indices to runtime handles, separating imported and own definitions.
  • Store: the global owner of all wasm runtime objects; uses arena-style indices (not raw pointers) so the GC and JS bindings can hold references safely.

Acceptance criteria:

  • Unit tests cover memory grow semantics (including failure when exceeding max), bounds checks on every numeric load/store width, table grow + element init, global mutability enforcement, and module instance index translation.
  • All data structures live in we-wasm; no execution logic yet; no JS coupling.
  • cargo clippy --workspace -- -D warnings passes; 100% safe Rust; zero external dependencies.
sign up or login to add to the discussion
Labels

None yet.

assignee

None yet.

Participants 1
AT URI
at://did:plc:meotu43t6usg4qdwzenk4s2t/sh.tangled.repo.issue/3mm2tkeqpbh27