ABI

An ABI Application binary interface is the low level convention with which machine code interacts with each other.

Since WASM is pretty primitive and language agnostic, there is a unique opportunity to define a new ABI! One which at least contains a minimal concept of classes.

That is: the data representation of types and the calling convention how these types are passed.

designing and ABI is no simple feat. if only all the smart hats that design the wonderful swift could get together and create a slightly different new ABI from all the mistakes & things that they've learned:
https://gankra.github.io/blah/swift-abi/

Angle abi

⚠️ preliminary, subject to changing!

Angle data in the wasm linear memory (and in host memory) is stored in a canonical univeral format:

struct Any_Header {
    Type header;// type / kind OF the object / container, e.g. Array, String, [[Node]]
    Type type;  // type WITHIN the container, e.g. generics or Node{.type=
    int length; // count of elements WITHIN the container, not sizeof()
    void *data; // ⚠️ continuation in memory OR pointer to data!
    // void *extra_fields… in objects without data continuation
};

The internal abi makes use of the memory layout of wasp nodes.

Calling convention

All non-primitive functions which take or return the univeral type node, that is any class, object or data, uses the following calling convention:

When multi-value is available, everything gets passed as a pair of ( Value, Type ) When multi-value is not available, everything gets passed as a smart-pointer. See source code for details.

Canonical ABI

The Wasm consortium grasped the unique opportunity by defining a Canonical ABI wit / wasm world Component Model MVP

Thanks to multi-value being already a defactor standard in wasm, the Angle ABI fully makes use of it:

All functions are polymorphic in parameter and return types: each value is a pair of TypedValue(int32,i64) In fact the pair (int32 i64) is always easy to read as in the Angle ABI int32 is always the type i64 is always the value, now matter what.

Since our ValueType is different from the wasm-internal Valtype (int32 = 0x7f …), we can still use a sprinkle of magic on them and treat them as smart-pointers. Another rationale for using i32 as pointers and i64 as numbers/values is that 99.9% percent of functions handle types other than int32.

The value can still be a pointer (if the type indicates so), but it shouldn't be a 64bit smart-pointer as there is simply no need for them.

Internally, within functions i32 can still be used for counters, loops etc. So the trick would be to use long whenever the keyword int appears in angle variables, but use int whenever the variables are not exposed. Since users expect int only to represent i32 values, there is no loss in precision if long is cast to int when calling external imports...

Interesting path: add wasm-unknown-unknown-angle as target for rust etc

C interops

⚠️ depending on optimization techniques and so on, there is no generic relyable interface to compiled c functions

WASI

https://github.com/WebAssembly/WASI/blob/main/legacy/application-abi.md

A command exports a function named _start, with no arguments and no return values.

_start is the default export which is called when the user doesn't select a specific function to call. Commands may also export additional functions, (similar to "multi-call" executables), which may be explicitly selected by the user to run instead.

Except as noted below, commands shall not export any mutable globals, tables, or linear memories.

Command instances may assume that they will be called from the environment at most once. Command instances may assume that none of their exports are accessed outside the duration of that call.

All other modules are reactors. A reactor may export a function named _initialize, with no arguments and no return values.