One other current limitation is that my build process is just a shell script. I'm not sure yet how to integrate new build targets into the HPy build system.

On Sun, Dec 27, 2020 at 2:49 PM Paul Prescod <paul@prescod.net> wrote:

For anyone who is interested, a very rough implementation of an extension ABI based on HPy and WASM is here:

https://github.com/hpyproject/hpy/compare/master...prescod:feature/wasm-prot...

This means that on any platform (operating system or CPU/ISA) where wasmer works, a single binary extension library can run without porting.

Status and limitations:

There are only about 50 lines of C code other than the generated stubs/trampolines. Most of it is written with ctypes/Python.

Currently it supports exactly enough APIs to run "pof.c" and no more. Other modules will probably generate "missing function" errors which are usually easy to fix with Python code.

It leaks memory like crazy. Handle cleanup is nearly non-existent.

Currently, it is tied specifically to Wasmer-Python and Wasmer-Python binaries only exist for X86, but in theory it could also be integrated with pywasm which has only a small dependency on NumPy and no other C dependencies. Which would mean that these binaries would run (slowly!) even on Python platforms with no native support for WASM.

For example, many modules don't have Mac ARM builds yet, but with WASM they would have a slow build available on "day 1", and a faster one when Python Wasmer is ported and then faster again when native builds are ported.

I'd like to make the abstraction layer that allows it target the "fastest" WASM engine available and fallback to slower ones as necessary.

I don't know if I will have time to take the prototype to production, but I'd be more motivated if anyone else pops up who is interested in this topic and would like to work together. Otherwise I may just document it as a prototype and put it on a shelf until someone interested in it pops up.

• Paul

One other current limitation is that my build process is just a shell script. I'm not sure yet how to integrate new build targets into the HPy build system.

On Sun, Dec 27, 2020 at 2:49 PM Paul Prescod <paul@prescod.net> wrote:

For anyone who is interested, a very rough implementation of an extension ABI based on HPy and WASM is here:

https://github.com/hpyproject/hpy/compare/master...prescod:feature/wasm-prot...

This means that on any platform (operating system or CPU/ISA) where wasmer works, a single binary extension library can run without porting.

Status and limitations:

There are only about 50 lines of C code other than the generated stubs/trampolines. Most of it is written with ctypes/Python.

Currently it supports exactly enough APIs to run "pof.c" and no more. Other modules will probably generate "missing function" errors which are usually easy to fix with Python code.

It leaks memory like crazy. Handle cleanup is nearly non-existent.

Currently, it is tied specifically to Wasmer-Python and Wasmer-Python binaries only exist for X86, but in theory it could also be integrated with pywasm which has only a small dependency on NumPy and no other C dependencies. Which would mean that these binaries would run (slowly!) even on Python platforms with no native support for WASM.

For example, many modules don't have Mac ARM builds yet, but with WASM they would have a slow build available on "day 1", and a faster one when Python Wasmer is ported and then faster again when native builds are ported.

I'd like to make the abstraction layer that allows it target the "fastest" WASM engine available and fallback to slower ones as necessary.

I don't know if I will have time to take the prototype to production, but I'd be more motivated if anyone else pops up who is interested in this topic and would like to work together. Otherwise I may just document it as a prototype and put it on a shelf until someone interested in it pops up.

• Paul