[Vm-dev] WebAssembly

[Clément Bera]

Hi,

On Thu, Dec 8, 2016 at 5:05 AM, Ben Coman <btc at openinworld.com> wrote:

>
> I've just bumped into WebAssembly and am curious what opportunities
> (or not) it might offer us.
> * https://medium.com/javascript-scene/what-is-webassembly-the-
> dawn-of-a-new-era-61256ec5a8f6#.60dghpaek
>
One approach could be to just compile our currently generated C code
> to WevAssembly via LLVM. Ronie's recent effort to produce a
> non-display minimal VM should help proof of concept here.
> * http://webassembly.org/docs/c-and-c++/
> * https://hacks.mozilla.org/2015/12/compiling-to-
> webassembly-its-happening/
> * http://cultureofdevelopment.com/blog/build-your-first-
> thing-with-web-assembly/
>
>

It should be possible to port the StackVM to WebAssembly through LLVM, but
many plugins have to be rewritten. Some people worked on making an easy to
bind interface for files, display and other plugin features already, but it
needs to be done. FFI plugin needs to be reimplemented too.

WebAssembly is an abstract assembly, so running the VM on it kind of makes
sense. It's not really running on top of a VM, it's running on top of an
abstract assembler to avoid assembly back-end dependencies.


> An obvious downside would be having a VM running on a VM.  But
> WebAssembly doesn't do garbage collection so at least it wouldn't
> double up on that.  Possibly there would be some double-up/conflict on
> JIT-ing, but there seems like there will be a facility for adding JIT
> and optimisation libraries, so possibly past investment in Cog is not
> lost.  Also perhaps(??) while WebAssembly is in its formative stage
> right now some primitives can be added to facilitate how Cog operates.
> * http://webassembly.org/docs/future-features/#platform-
> independent-just-in-time-jit-compilation
> * http://webassembly.org/docs/jit-library/
>
>
It's possible. You need the JIT to have a back-end to web assembly, which
is some work.

However, stack introspection is not possible currently (though it may be
added in the future). This means that the VM needs to maintain a shadow
stack for the GC to scan it with the current implementation. It requires
changes in the VM that are non trivial. It would be better to wait for
stack introspection to be available.


> Another approach may be to start with SqueakJS, and work out how the
> Cog JIT could be plugged into WebAssembly as a library that SqueakJS
> (and others?) could use.  If its architecturally possible this might
> broaden the exposure of Cog(??). What would WebAssembly require to
> facilitate using Cog?
>

I believe it's easier to use directly the Cog compiled to web assembly. The
most difficult part is to make the JIT compliant anyway.


>
> Of course all plates are full, but now seems the ideal time time to
> get involved.
> WebAssembly browser preview seeking community feedback concluding Q1 2017.
> https://www.infoq.com/news/2016/11/webassembly-browser-preview
> http://webassembly.org/roadmap/
> https://github.com/WebAssembly/design
>
> Chrome nightly builds available to test it
> http://thenextweb.com/dd/2016/03/15/webassembly-lands-
> chrome-canary-offering-glimpse-future-web/
>
> It would be amazing to run Cog in a web browser, and thus facilitate
> all our favourite Smalltalk dialects.


> Side thought: Craig's work to incrementally download a running image
> could be useful to reducing web page startup time.
>

There's already multiple things like Amber, PharoJS, SqueakJS, Craig's work.

Another thing we could do: now that the JIT supports 4 sets of unsafe
operations, like Ronie's lowcode or the sista instructions, we could
support a DSL similar to webAssembly in Squeak/Pharo that compiles to
machine code though Cog's JIT...


>
> cheers -ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161208/71a731d2/attachment.html>