Raw WebAssembly ABI

Lists the exported C-style functions, pointer/length conventions, global runtime lock, result buffers, and compatibility obligations for host callers.

Experimental
Last verified
2026-06-25 00:00 UTC
Updated
Reading time
2 minutes

Lists the exported C-style functions, pointer/length conventions, global runtime lock, result buffers, and compatibility obligations for host callers.

Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.

Supplied WASM exports
alloc(length: usize) -> *mut u8
dealloc(pointer: *mut u8, length: usize)
init_runtime() -> u32
load_model(pointer: *const u8, length: usize) -> u32
set_sampling_config(temperature: f32, top_k: u32, top_p: f32, seed: u64) -> u32
generate(pointer: *const u8, length: usize, max_new_tokens: u32) -> u32
generate_next_token() -> u32
last_result_ptr() -> *const u8
last_result_len() -> usize
get_diagnostics_ptr() -> *const u8
get_diagnostics_len() -> usize
reset_context() -> u32
free_model() -> u32

State container

A process-global Mutex<Option<Runtime>> serializes access. The ABI is synchronous and single-operation-at-a-time. It does not expose cancellation, streams, sessions, multiple loaded models, or concurrent inference.

Result ownership

Result and diagnostics pointers reference runtime-owned buffers. The host must read them before a subsequent call mutates the buffers. The host does not deallocate these pointers.

Compatibility rule

Any ABI change requires an explicit version negotiation or a coordinated app/runtime release. Function presence alone is not sufficient; error-code values, pointer lifetime, encoding, and state-transition semantics are part of the contract.

Scope

This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.

Engineering considerations

  • Identify the source, version, target environment, and owner.
  • Separate observed values from estimates and externally reported values.
  • Record trade-offs, unsupported cases, and fallback behavior.
  • Link performance statements to a compatible benchmark methodology.

Verification questions

  • What exact artifact, revision, backend, and environment were reviewed?
  • Which assumptions could change the result?
  • Which data should be retained so another engineer can reproduce the conclusion?