Hi all--
I wrote a WebAssembly version of interpretOne() from the SqueakJS VM, and am now running it in that VM (very slowly for now, because it has to call other JS functions and manipulate JS memory). I've run the first several thousand instructions of resuming a Caffeine snapshot, and can switch back and forth between the JS and WASM versions of interpetOne() as the system runs.
Over time, I can rewrite the other JS functions, and use WASM memory for the object memory. I'm looking forward to a big speedup, ultimately. I've already gotten some nice speedups from rewriting some of the inner BitBLT plugin functions in WASM.
More details at [1].
cheers! Craig
[1] https://tinyurl.com/thiscontext-2023-04-14
-- Craig Latta :: research computer scientist :: Black Page Digital :: Berkeley, California :: 663137D7940BF5C0AF :: C1349FB2ADA32C4D5314CE ::
Hi Craig,
On Fri, Apr 14, 2023 at 11:07:19PM -0700, Craig Latta wrote:
Hi all--
I wrote a WebAssembly version of interpretOne() from the SqueakJS
VM, and am now running it in that VM (very slowly for now, because it has to call other JS functions and manipulate JS memory). I've run the first several thousand instructions of resuming a Caffeine snapshot, and can switch back and forth between the JS and WASM versions of interpetOne() as the system runs.
Over time, I can rewrite the other JS functions, and use WASM
memory for the object memory. I'm looking forward to a big speedup, ultimately. I've already gotten some nice speedups from rewriting some of the inner BitBLT plugin functions in WASM.
Thanks for the update, this is interesting work.
While this may not be directly applicable, I'll mention it just in case it might be helpful in dealing with the object pointer mapping. In the compiled VMs, the low level memory mapping is done in C macros in sqMemoryAccess.h, but there is also a Smalltalk (slang) version in package MemoryAccess in the VMMaker repository that eliminates use of the macros, and that runs at about the same speed as the macros (thanks to the slang inliner, which is really very good).
To me, the Smalltalk version is much easier to read and understand than the C macro version, so maybe this will be of some help as you get into the WASM object memory implementation.
See http://wiki.squeak.org/squeak/6081 for background. That page is a little out of date (the "external support code requirements" are no longer required) but otherwise accurate, and the package still works fine on an up to date interpreter VM today.
Dave
More details at [1]. cheers! Craig
vm-dev@lists.squeakfoundation.org