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 https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-a...
WebAssembly architecture for Go https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxC...
From WebAssembly Illustrated...
https://takenobu-hs.github.io/downloads/WebAssembly_illustrated.pdf * 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 https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md
Garbage Collection (proposal) https://github.com/WebAssembly/gc
cheers -ben
Hi Ben,
On Fri, Mar 15, 2019 at 2:13 AM Ben Coman btc@openinworld.com 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
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-a...
WebAssembly architecture for Go
https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxC...
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... https://takenobu-hs.github.io/downloads/WebAssembly_illustrated.pdf
- 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 https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md
Garbage Collection (proposal) https://github.com/WebAssembly/gc
cheers -ben
On Sun, 17 Mar 2019 at 02:49, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben,
On Fri, Mar 15, 2019 at 2:13 AM Ben Coman btc@openinworld.com 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
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-a...
WebAssembly architecture for Go
https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxC...
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
On Tue, 19 Mar 2019 at 16:47, Ben Coman btc@openinworld.com wrote:
On Sun, 17 Mar 2019 at 02:49, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben,
On Fri, Mar 15, 2019 at 2:13 AM Ben Coman btc@openinworld.com 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
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-a...
WebAssembly architecture for Go
https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxC...
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...
https://takenobu-hs.github.io/downloads/WebAssembly_illustrated.pdf * Slide 23 - Call stack
I haven't spent any time trying to understand the code in this link, but does it give some hints...? https://github.com/llvm-mirror/llvm/blob/master/lib/Target/WebAssembly/WebAs...
Something formal... https://webassembly.github.io/spec/core/exec/runtime.html#frames
At a stretch for hints, V8 handling of walking WebAssembly frames... https://github.com/v8/v8/blob/master/src/isolate.cc#L1664-L1690
cheers -ben
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?
P.S. I vaguely remember a concern about non-local-returns described as "A blockClosure has a direct pointer to its outerContext, the context that created the blockClosure. With this variable, the blockClosure can ... perform non local return. ... A blockClosure can return either to its sender (see our example with false as argument) or to its homeContext sender. This non local returns requires the virtual machine to walk up the stack until it finds the stack frame to return to. This can be done only using the outerContext field." https://clementbera.wordpress.com/2015/01/21/context-and-blockclosure-implem...
I wonder if such walking-the-stack could be helped by using WebAssembly traps described as "Traps are bubbled up through nested instruction sequences" https://webassembly.github.io/spec/core/exec/runtime.html#administrative-ins...
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
Hi Levente,
On Mar 18, 2019, at 1:50 PM, Levente Uzonyi leves@caesar.elte.hu 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
On Mon, Mar 18, 2019 at 7:58 PM Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 18, 2019, at 1:50 PM, Levente Uzonyi leves@caesar.elte.hu
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.
The WebAssembly stack is too restrictive to directly host the Smalltalk stack. By design, it's not possible to get an address into the stack. For C code, Emscripten places locals that have their address taken into a shadow stack that lives in WebAssembly memory. A direct translation from Slang to WebAssembly would have to do the same.
On Fri, 15 Mar 2019 at 17:12, Ben Coman btc@openinworld.com 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...
Another article that makes me curious about the implications for opensmalltalk-vm. I suppose the same as we have Windows/Linux/OSX platforms we might have a WASI platform?
Standardizing WASI: A system interface to run WebAssembly outside the web
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-in...
cheers -ben
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Eliot Miranda -
Levente Uzonyi -
Ryan Macnak