Ponyc: Investigate compilation to WebAssembly

[Praetonus]

In the same vein as GPUs (#1330) LLVM has an experimental WebAssembly backend. A Pony-in-a-browser proof of concept would be great.

[jemc]

Possibly helpful information from Rust land: https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627

[pannous]

ping?

[jemc]

@pannous - I don't think anyone is working actively on this at the moment.

If anyone is interested in working on this we can try to provide some pointers about how to proceed.

[winksaville]

I'm interested in this too, so I'll help where I'm able.

On Thu, Dec 28, 2017, 11:19 AM Joe Eli McIlvain [e-mail]
wrote:

@pannous https://github.com/pannous - I don't think anyone is working
actively on this at the moment.

If anyone is interested in working on this we can try to provide some
pointers about how to proceed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ponylang/ponyc/issues/1407#issuecomment-354342431,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-hHEQip188-zUY2dD4tI4AhqSLOSR4ks5tE-m6gaJpZM4KtD_8
.

[Praetonus]

There are basically 3 things that need to be done.

• At the runtime level, we need to add browser-compatible implementations of the platform-specific parts of the runtime (threading, virtual memory allocation, IO and exception handling.)
• At the language level, we need to establish how the FFI would look like on the wasm target. Things like, do we allow calling to Javascript, or only to C compiled to wasm? If we allow Javascript calls, how do we validate these calls, given that Javascript is dynamically typed and Pony is statically typed? How does the other side look like, when calling from Javascript into Pony? This step requires an RFC.
• At the compiler level, we need to make sure that the code generator works correctly with the LLVM wasm target. We also need to implement the FFI design rules established during the language step.

[jemc]

@Praetonus We could potentially dodge the FFI question for a little while by only allowing FFI calls to the libponyrt functions on the wasm platform, which would probably themselves be compiled together with the program using whole-program-optimization, right?

[Praetonus]

@jemc Possibly, yes. We could also delay the runtime changes by adding blank implementations of the relevant modules. It would result in a single threaded, malloc-based runtime with no IO and no exceptions but it would work for basic tests.

[matthewp]

I'm not sure if wasm can launch web workers or not, but given pony's unique actor model, having actors run in web workers would differentiate it from other languages that are compiling to wasm.

[michaelsbradleyjr]

@matthewp perhaps Shared Memory and Atomics for ECMAScript is also relevant at this point? Not sure.

N.B. the proposal has been merged into the ECMAScript specification as of Feb 2017.

[winksaville]

An FYI, I've added WebAssembly code generation to the llvm/clang to #2663.

[SeanTAllen]

Is there any reason for bundling those together in a single PR @winksaville. My gut reaction is that they should be separate PRs.

[winksaville]

@SeanTAllen, adding support to llvm/clang for WebAssembly was trivial, I only needed to add -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly to one command in the lib/llvm/Makefile. Support for all other targets remain the same and since #2663 is just a proof of concept I thought it would be help to show another advantage of building llvm/clang ourself.

But to answer you question, we can definitely add support for WebAssembly in the tool chain in a separate PR.

[creatorrr]

@winksaville @SeanTAllen any update on this? Happy to help?

[SeanTAllen]

@creatorrr no one is working on this. if you'd like the help out, ping folks on the zulip.

https://ponylang.zulipchat.com/#narrow/stream/189952-compiler-discussion

[autodidaddict]

Some random thoughts:
Wasm specification makes no assumption about the existence of a browser. Go's implementation baked in the JavaScript interaction and usage patterns and as such is nearly (and in my use case completely) unusable for non-browser hosts. It's been frustrating to see so many tight couplings with the browser in languages building out their first iteration of Wasm support.

I know my opinion doesn't mean much here, but as the Wasm support for Pony is built out, keeping an eye toward clean separation between supporting the Wasm specification as a compile target and supporting the JavaScript FFI as something _separate_ would avoid blocking people from using Wasm in non-browser hosts. One of Wasm's key value adds is true portability, but if different languages break that portability by assuming the runtime host is JavaScript or JS-like, then it detracts from Wasm's value.

tl;dr - supporting imports, exports, and Wasm's pure-numeric parameters and return values is one concern, and wrapping that with a JavaScript-friendly calling convention and allocation pattern should (imho) be a totally separate, _opt-in_, concern.

[Shaping]

@autodidaddict I agree completely.