Lime is a series of defined and stable subsets of WebAssembly features that producers and consumers can both use to promote interoperability. It is intended to be implemented by producers such as LLVM, using features such as LLVM's concept of target CPUs. Once a Lime configuration is defined, it will be stable and not add or remove any features.
Lime configuration names include a version number, such as "Lime1". When there is a need to add or remove features, a new Lime configuration with a new version number will be defined, such as "Lime2".
Lime aims for features which do not involve significant new runtime cost or complexity, and can be implemented in mobile devices and other highly constrained environments.
The name "Lime" was inspired by abbreviating Linear Memory, as this series currently lacks wasm-gc and is therefore focused on linear-memory languages or language implementations.
The following Lime configurations have been defined:
The Lime1 target consists of WebAssembly 1.0 plus the following standardized (phase-5) features:
- mutable-globals
- multivalue
- sign-ext
- nontrapping-fptoint
- bulk-memory-opt
- extended-const
- call-indirect-overlong
This set of features can be tested for by using the Lime1 test. This is not a comprehensive conformance test, but it does at least minimally use all of the features mentioned above.
WebAssembly features sometimes contain several features combined into a single proposal to simplify the standardization process, but can have very different implementation considerations. This section defines subsets of standardized features for use in Lime configurations.
bulk-memory-opt is a subset of the bulk-memory feature that contains just the
memory.copy and memory.fill instructions.
It does not include the table instructions, memory.init, or data.drop.
memory.init and data.drop require implementations to support passive data
segments, which entail significant new runtime complexity.
The table.* instructions require implementations to support mutable tables,
which is not commonly needed in linear-memory-oriented languages.
call-indirect-overlong is a subset of the reference-types feature that contains
just the change to the call_indirect instruction encoding to change the zero
byte to an LEB encoding which may have an overlong encoding.
It does not include the actual reference types.
Actual reference types imply significant new runtime complexity.
The call-indirect overlong instruction encoding is expected to be very easy to support in any decoder, and it does not entail any new runtime complexity.