Supported WASM Feature Extensions
Wasm2Glulx supports 100% of the WebAssembly 1.0 Core Specification, and most of the current 2.0 draft: as of the 2024-09-21 draft, everything except the SIMD instructions. In addition, a number of feature extensions that are not (or not yet) part of the core spec are either supported or planned to be supported. Here is the support status of every feature extension defined by the WebAssembly working group:
The following features are fully supported:
- Bulk Memory Operations
- Multi-value
- Reference Types
- Non-trapping float-to-int Conversions
- Sign-extension Operators
The following features are not yet supported, but planned:
- Fixed-width SIMD
- Glulx does not natively support SIMD. It's straightforward to emulate, albeit very tedious because there are a huge number of instructions to implement. Adding this will be a low priority unless a compelling use case comes up, which is doubtful.
- Relaxed SIMD
- Tail Call
- Coming soon.
- Typed Function References
- Awaiting upstream support from Walrus (the library that Wasm2Glulx uses for parsing WebAssembly).
- Exception Handling with exnref
- Awaiting upstream support.
- Threads
- Yes, Wasm2Glulx will be able to support this even though Glulx is strictly single-threaded. The Threads proposal really just defines atomics and synchronization primitives, and doesn't define any way to spawn a thread, leaving that up to the embedder. So, the atomics can be implemented as ordinary instructions and the synchronization primitives can be no-ops.
- Custom Page Sizes
- Too early a draft right now, but should be easy to support once fleshed out.
The following features are not planned:
- Branch Hinting
- Wasm2Glulx accepts input which includes branch hints, but it ignores them.
- Multiple Memories
- This is planned for in the sense that Wasm2Glulx is architected in a way that will make it possible to add in the future if necessary. But, doing so would significantly complicate things and add some runtime overhead, so it will be avoided unless a compelling use case comes up.
- Garbage Collection
- This would be a massive amount of work to implement, on top Multiple Memories support which would be a prerequisite. Glulx doesn't have a garbage collector, and any polyfill that Wasm2Glulx could provide would not be any more (and probably less) efficient than the polyfills that GCed languages targeting WebAssembly already usually provide.
- Memory64
- Impossible, since Glulx is a 32-bit machine.
- Instrumentation and Tracing Technology
- This proposal doesn't seem to be fleshed out and seems to be dead.
- Stack Switching
- Infeasible without first extending Glulx.
- Legacy Exception Handling
- This feature is deprecated. Its replacement, Exception Handling with exnref, is planned.
The following features are N/A. They relate to aspects of WebAssembly that aren't applicable to Wasm2Glulx, such as its JavaScript embedding.
- JS BigInt to Wasm i64 Integration
- Custom Text Format Annotations
- Extended Constant Expressions
- Constant expressions are functions of imported constant globals. Since Wasm2Glulx doesn't make any constant globals available for import, it's impossible to write a well-typed extended constant expression.
- Import/Export of Mutable Globals
- Exported mutable globals are accepted but ignored.
- JS String Builtins
- ESM Integration
- JS Promise Integration
- Type Reflection for JS API
- Web Content Security Policy