Wasm global imports

[ashtonmeuser]

This ticket captures making Wasm module global imports accessible to GDScript via Godot Wasm. The following specs give some info regarding Wasm module global.
Wasm mutable global spec
MDN JS reference

At the time of writing (v0.2.2), the following global functionality exists.

• Global export read
• Global export write
• Global import read
• Global import write

A property of a GDScript script should be able to be imported as a global and read by a Wasm module. Because GDScript properties can not be read or written using the Wasm C API's expected pointer interface, global setters and getters are required. This precludes using the C API and requires the C++ API instead. Using the C++ API is blocked by wasmerio/wasmer#3754.

[ashtonmeuser]

May take a while to trickle down to Wasmer, but this would also suffice. This is not entirely correct. A bespoke way of representing module globals is likely required.

[fire]

What is this?

[ashtonmeuser]

@fire Added some more context to the ticket. Essentially, there is a bit of a technical limitation re: implementing mutable global imports. Below is my understanding of Wasm import globals and may not be wholly accurate.

Modules can accept mutable global imports. These are basically treated as a pseudo-import-memory. When the module mutates the global import, it writes the value to this address (actually handled by the runtime which writes the value to a pointer). My intent for global imports was to accept the from GDScript the same as import functions i.e. target and method in the case of functions and target and property in the case of globals. I anticipated passing these in along side functions which is why there is an import dictionary passed to instantiate() that, as of v0.2.2, can only take a single key of functions. The plan was to slot globals in nicely here. For example:

var module = Wasm.new()
var imports = {
  "functions": {
    "env.myfunc": [self, "myfunc"],
  },
  "globals": {
    "env.myglobal": [self, "myglobal"]
  },
}
module.load(buffer, imports)

Here, the GDScript instantiating the module (self) has a property myglobal. The Wasm module should be able to set the value of this property. The issue is that we'd need to pass the module the pointer to the value underlying the Godot Variant. Even if that can be done, it wouldn't be perfect e.g. 32 bit ints would be corrupted as Godot only deals with 64 bit ints.

Note that more functionality around globals is totally possible today without any rethinking but I've deferred until coming up with a plan to support globals completely (including the case mentioned above).

Happy to hear any ideas.