Investigate compilation to WebAssembly

Praetonus commented 8 years ago

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 commented 8 years ago

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

pannous commented 6 years ago

ping?

jemc commented 6 years ago

@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 commented 6 years ago

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 notifications@github.com 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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

SeanTAllen commented 6 years ago

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

winksaville commented 6 years ago

@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 commented 5 years ago

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

SeanTAllen commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

@autodidaddict I agree completely.

jemc commented 3 years ago

Some minor progress has been made in this PR, which lays the ground work for compiling the runtime with Emscripten: https://github.com/ponylang/ponyc/pull/3906

What's still missing (as described in that PR) is an Emscripten-friendly implementation of the Pony ASIO subsystem, as Emscripten does not support epoll at this time.

ponylang / ponyc

Investigate compilation to WebAssembly #1407