Hello all! As some of you might be aware, there has been a lot of progress in the web-world in developing [WebAssembly](https://webassembly.org/). Many environments and languages can now compile to the wasm binary format. Projects are doing things like [putting full Python interpreters and environments in the browser](https://github.com/iodide-project/pyodide), etc. There is even a nascent movement to come up with a consistent [system interface standard](https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-in...) for WebAssembly, allowing developers to run wasm code on any platform -- not just the web.
My question is this: what would it take to get the opensmalltalk-vm to compile to WebAssembly and has anyone involved with it considered the option so far?
There would be a great many advantages to running a Smalltalk in the browser this way.
$10,000,000 usa
On 2019-03-28, at 2:06 PM, johnmci notifications@github.com wrote:
$10,000,000 usa
At least.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim World Ends at Ten! Pictures at 11 on Fox News!
On Fri, 29 Mar 2019 at 05:17, tim Rowledge tim@rowledge.org wrote:
On 2019-03-28, at 2:06 PM, johnmci notifications@github.com wrote:
$10,000,000 usa
At least.
Really? So ten years for 5 x $200k programmers? I'd hope we could do better than that ;)
On Fri, 29 Mar 2019 at 08:16, Craig Latta notifications@github.com wrote:
In the meantime, I'm getting very good results running Squeak in web browser and on Node with SqueakJS. The simple bytecode-to-JS dynamic translator that Bert wrote for it is a big win. You get a decent translation of bytecodes to native code via the underlying JS engine (V8 et al).
btw, Is that then a Slang to SqueakJS writer? Or is the bytecode-to-JS happening as some other level?
cheers -ben
Hi Ben--
In the meantime, I'm getting very good results running Squeak in web browser and on Node with SqueakJS. The simple bytecode-to-JS dynamic translator that Bert wrote for it is a big win. You get a decent translation of bytecodes to native code via the underlying JS engine (V8 et al).
btw, Is that then a Slang to SqueakJS writer? Or is the bytecode-to-JS happening as some other level?
It takes a Smalltalk CompiledMethod object, and transcribes the instructions (bytecodes) into a JavaScript method, and makes sure to run that instead, whenever the CompiledMethod would normally run. Then V8 optimizes the hell out of the native code for that transcribed JS method. It's pretty neat, and makes a huge difference for lots of things, including the UI.
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com +31 6 2757 7177 + 1 415 287 3547
On Sat, 30 Mar 2019 at 15:30, Craig Latta craig@blackpagedigital.com wrote:
Hi Ben--
In the meantime, I'm getting very good results running Squeak in web browser and on Node with SqueakJS. The simple bytecode-to-JS dynamic translator that Bert wrote for it is a big win. You get a decent translation of bytecodes to native code via the underlying JS engine (V8 et al).
btw, Is that then a Slang to SqueakJS writer? Or is the bytecode-to-JS happening as some other level?
It takes a Smalltalk CompiledMethod object, and transcribes theinstructions (bytecodes) into a JavaScript method, and makes sure to run that instead, whenever the CompiledMethod would normally run. Then V8 optimizes the hell out of the native code for that transcribed JS method. It's pretty neat, and makes a huge difference for lots of things, including the UI.
When is the source code for that transcriber?
cheers -ben
[The SqueakJS VM] takes a Smalltalk CompiledMethod object, and transcribes the instructions (bytecodes) into a JavaScript method, and makes sure to run that instead, whenever the CompiledMethod would normally run. Then V8 optimizes the hell out of the native code for that transcribed JS method. It's pretty neat, and makes a huge difference for lots of things, including the UI.
Where is the source code for that transcriber?
https://github.com/bertfreudenberg/SqueakJS/blob/master/jit.js
Used by:
https://github.com/bertfreudenberg/SqueakJS/blob/master/vm.js
-C
-- Craig Latta Black Page Digital Amsterdam :: San Francisco craig@blackpagedigital.com +31 6 2757 7177 + 1 415 287 3547
On Sat, 30 Mar 2019 at 16:57, Craig Latta craig@blackpagedigital.com wrote:
[The SqueakJS VM] takes a Smalltalk CompiledMethod object, and transcribes the instructions (bytecodes) into a JavaScript method, and makes sure to run that instead, whenever the CompiledMethod would normally run. Then V8 optimizes the hell out of the native code for that transcribed JS method. It's pretty neat, and makes a huge difference for lots of things, including the UI.
Where is the source code for that transcriber?
https://github.com/bertfreudenberg/SqueakJS/blob/master/jit.js Used by: https://github.com/bertfreudenberg/SqueakJS/blob/master/vm.js
Thx. Really interesting perusing that. Now was vm.js completely hand crafted? Or generated somehow from VMMaker Slang code?
cheers -ben
Yes, I've been following WASM since it attained full browser coverage in 2017. I've built the OpenSmalltalk stack interpreter with emscripten, no major gotchas. Of course we want a WASM Cog. We're waiting for WASM to do garbage collection, and provide an API for running your own generated native code. I expect both of these to arrive in the next two years.
In the meantime, I'm getting very good results running Squeak in web browser and on Node with SqueakJS. The simple bytecode-to-JS dynamic translator that Bert wrote for it is a big win. You get a decent translation of bytecodes to native code via the underlying JS engine (V8 et al).
It takes a Smalltalk CompiledMethod object, and transcribes the instructions (bytecodes) into a JavaScript method, and makes sure to run that instead the next time the CompiledMethod would normally run. Then V8 optimizes the hell out of that transcribed JS method. It's pretty neat, and makes a huge difference for lots of things, including the UI.
Do you want good performance? Do you want to use the ManagedObject layer provided by WASM or OpenSmalltalk-VM own GC? The latter would require to keep a shadow stack since the WASM stack cannot be walked easily for GC. Do you want to JIT to WASM or just an interpreter?
My main concern is that implementing high level languages on top of WASM is just starting to be possible in a nice way, and I think we should wait for other people to struggle and to re-negotiate some APIs with the WASM people before trying. Each WASM API change have to be validated by multiple people from different companies after being prototyped, so it can take time.
Depending on what you want it may not be 10M$, but if you want a solid high-performance low-memory-footprint runtime and you don't want to wait multiple years for other people to struggle implementing other languages first, that would be a fair initial investment.
On Thu, Mar 28, 2019 at 9:36 PM Eric Gade notifications@github.com wrote:
Hello all! As some of you might be aware, there has been a lot of progress in the web-world in developing WebAssembly https://webassembly.org/. Many environments and languages can now compile to the wasm binary format. Projects are doing things like putting full Python interpreters and environments in the browser https://github.com/iodide-project/pyodide, etc. There is even a nascent movement to come up with a consistent system interface standard https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ for WebAssembly, allowing developers to run wasm code on any platform -- not just the web.
My question is this: what would it take to get the opensmalltalk-vm to compile to WebAssembly and has anyone involved with it considered the option so far?
There would be a great many advantages to running a Smalltalk in the browser this way.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/387, or mute the thread https://github.com/notifications/unsubscribe-auth/AhLyWzlKbLZ9XGdp_9AaYbo8q1Lg3k4_ks5vbSfpgaJpZM4cRFsD .
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Clément Béra -
Craig Latta -
Craig Latta -
Eric Gade
-
johnmci
-
tim Rowledge