tracking WebAssembly

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

tracking WebAssembly

Ben Coman
 

Found some recent WebAssembly articles that may impact issues previously raised as impediments to Smalltalk-on-WebAssembly.
Do these indicate anything useful for the possibility of running Squeak/Pharo on WebAssembly...

Calls between JavaScript and WebAssembly are finally fast


WebAssembly architecture for Go


From WebAssembly Illustrated...
* Slide 16 - If Slang could directly output WebAssembly bytecode, I presume the Interpreter lookup table could be modeled as a "call_indirect #n" of functions compiled to a WebAssembly "Table"
* Slide 39-40 - I wonder if the Host environment being able to mutate the Table means by default a newly downloaded Smalltalk program would be running as an Interpreter, but you could a browser plugin for the JIT that updated Table for JIT'd methods.
* Slides 48-51 - Alternatively, I wonder if a "form" of JITing could be dynamically creating a WebAssembly bytecode module that is then immediately loaded and the function called, and a new module loaded for each new JIT output. 
"Platform-independent JIT" is mentioned at https://webassembly.org/docs/future-features/


WebAssembly GC proposal including a tagging scheme for unboxed small scalars 


Garbage Collection (proposal)

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: tracking WebAssembly

Eliot Miranda-2
 
Hi Ben,

On Fri, Mar 15, 2019 at 2:13 AM Ben Coman <[hidden email]> wrote:
 
Found some recent WebAssembly articles that may impact issues previously raised as impediments to Smalltalk-on-WebAssembly.
Do these indicate anything useful for the possibility of running Squeak/Pharo on WebAssembly...

Calls between JavaScript and WebAssembly are finally fast


WebAssembly architecture for Go

Good to read.  What can you find that discusses the range of stack frame formats?  To map the StackInterpreter to WebAssembly conveniently we would need there ability to store the current method/closure in each frame.
 
From WebAssembly Illustrated...
* Slide 16 - If Slang could directly output WebAssembly bytecode, I presume the Interpreter lookup table could be modeled as a "call_indirect #n" of functions compiled to a WebAssembly "Table"
* Slide 39-40 - I wonder if the Host environment being able to mutate the Table means by default a newly downloaded Smalltalk program would be running as an Interpreter, but you could a browser plugin for the JIT that updated Table for JIT'd methods.
* Slides 48-51 - Alternatively, I wonder if a "form" of JITing could be dynamically creating a WebAssembly bytecode module that is then immediately loaded and the function called, and a new module loaded for each new JIT output. 
"Platform-independent JIT" is mentioned at https://webassembly.org/docs/future-features/


WebAssembly GC proposal including a tagging scheme for unboxed small scalars 


Garbage Collection (proposal)

cheers -ben


--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: tracking WebAssembly

Levente Uzonyi
In reply to this post by Ben Coman
 
Wouldn't it be easier to just use emscripten to compile the current C code
directly to wasm?
I mean, it would probably be a smaller undertaking to create the necessary
bindings/plugins for emscripten than to generate wasm code directly from
VMMaker and rewrite the platform code.

Levente
Reply | Threaded
Open this post in threaded view
|

Re: tracking WebAssembly

Eliot Miranda-2
 
Hi Levente,

> On Mar 18, 2019, at 1:50 PM, Levente Uzonyi <[hidden email]> wrote:
>
> Wouldn't it be easier to just use emscripten to compile the current C code directly to wasm?
> I mean, it would probably be a smaller undertaking to create the necessary bindings/plugins for emscripten than to generate wasm code directly from VMMaker and rewrite the platform code.

Sure, but running a stack machine virtually above another stack machine is going to be far less efficient than mapping the Cog Smalltalk stack to the WebAssembly stack.  So it’s an issue of performance and ambition.  I tend to choose the ambitious route, within affordability constraints.

>
> Levente
Reply | Threaded
Open this post in threaded view
|

Re: tracking WebAssembly

Ben Coman
In reply to this post by Eliot Miranda-2
 


On Sun, 17 Mar 2019 at 02:49, Eliot Miranda <[hidden email]> wrote:
 
Hi Ben,

On Fri, Mar 15, 2019 at 2:13 AM Ben Coman <[hidden email]> wrote:
 
Found some recent WebAssembly articles that may impact issues previously raised as impediments to Smalltalk-on-WebAssembly.
Do these indicate anything useful for the possibility of running Squeak/Pharo on WebAssembly...

Calls between JavaScript and WebAssembly are finally fast


WebAssembly architecture for Go

Good to read.  What can you find that discusses the range of stack frame formats?  To map the StackInterpreter to WebAssembly conveniently we would need there ability to store the current method/closure in each frame.

Can you point me to the code where this happens?

And is there a good general description of this that I could refer to if I was discussing this with someone outside our community?

cheers -ben