Proposal: Smallest and Stable Runtime Interface Spec of wasm32 VM is Wanted ...

[remuscl]

For applications which want to use wasm32 as a embeded vm engine (not only in the browsers, but in everywhere as long as we can image), it is still hard to implement the runtime interface now because there is no spec and guarantee about it (when you want to use the emcc/emmake... toolchain meanwhile).

Maybe it is important and pretty worthy to write such spec.

Ps:
For example, there is no spec about the detailed definitions of the runtime interface functions like below:

  (import "env" "memory" (memory (;0;) 256 256))
  (import "env" "table" (table (;0;) 10 10 anyfunc))
  (import "env" "memoryBase" (global (;0;) i32))
  (import "env" "tableBase" (global (;1;) i32))
  (import "env" "DYNAMICTOP_PTR" (global (;2;) i32))
  (import "env" "tempDoublePtr" (global (;3;) i32))
  (import "env" "ABORT" (global (;4;) i32))
  (import "env" "STACKTOP" (global (;5;) i32))
  (import "env" "STACK_MAX" (global (;6;) i32))
  (import "global" "NaN" (global (;7;) f64))
  (import "global" "Infinity" (global (;8;) f64))
  (import "env" "enlargeMemory" (func (;0;) (type 2)))
  (import "env" "getTotalMemory" (func (;1;) (type 2)))
  (import "env" "abortOnCannotGrowMemory" (func (;2;) (type 2)))
  (import "env" "abortStackOverflow" (func (;3;) (type 3)))
  (import "env" "nullFunc_ii" (func (;4;) (type 3)))
  (import "env" "nullFunc_iiii" (func (;5;) (type 3)))
  (import "env" "___lock" (func (;6;) (type 3)))
  (import "env" "___setErrNo" (func (;7;) (type 3)))
  (import "env" "___syscall140" (func (;8;) (type 4)))
  (import "env" "___syscall146" (func (;9;) (type 4)))
  (import "env" "___syscall54" (func (;10;) (type 4)))
  (import "env" "___syscall6" (func (;11;) (type 4)))
  (import "env" "___unlock" (func (;12;) (type 3)))
  (import "env" "_emscripten_memcpy_big" (func (;13;) (type 0)))
  ... ...

[kripken]

I agree this is important and would be good to do.

It could be done as part of the modularization effort (#5828) - we can define clear interfaces on the modules, and docs for those should provide what is asked for here.

[appcypher]

Hi @kripken and co. You guys have created a truly spectacular project.

However, I'd like to know the progress towards creating a standard API specification as suggested by @remuscl.

New wasm runtimes are popping up every time and many of them are looking to support Emscripten. Some have achieved this to a certain degree but I wouldn't be too confident their implementation matches exactly with what Emscripten APIs expect.

I would have loved to help with this but I'm still new to Emscripten.

[kripken]

@appcypher I'm not aware of progress on specifying an API for emscripten apps to use. It depends on someone having the interest and the time to do it - maybe one of the interesting new runtime projects will want to? I can definitely help with advice and code review etc.

I may also eventually have time for this myself, but personally my main focus is on the Web target. For the Web, we may also want to design a new runtime API for emscripten eventually. I think that may happen, if it doesn't happen earlier, when wasm gets GC/DOM API support, as that may allow us to do completely new things in our JS/wasm interactions.

[rianhunter]

I've been compiling a list of necessary changes so that emscripten can support the compilation of runtime-neutral WASM files. Once I've finished porting an entire application to wasmjit using emscripten as it is I will submit a longer document on this issue so that we can discuss each change. I'm still learning new things which is why I think it's necessary to go through the porting effort first instead of suggesting changes without real-world experience.

[kripken]

@rianhunter sounds good, looking forward to that :)

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.