I've been working on a JIT compiler for Snap!. Snap! already has an experimental JIT compiler, but it doesn't support yields or custom blocks and doesn't seem to have been updated in some time.
Currently it can run Vee, although you need to set the "shapes" variable through the code before running it, and warp isn't working for whatever reason. I didn't test the other example projects.
Link: https://pkhead.github.io/snapjit/
(You can turn off the JIT compiler in settings)
This is a list of stuff I'm aware isn't currently functional:
Warp not working correctly in the situation Vee creates
Result bubbles
Continuations
Launch block
Tell/ask
Most yielding blocks don't work
Rendered rings show the stringified generator function (the compiled code) -- make it show Snap! code (maybe?)
Code doesn't recompile when a slot is changed (the cache becomes outdated. you have to re-place the block in order for it to recompile)
Currently rings are compiled along with the rest of the script -- compile them only when ran/called.
I'm thinking of also providing this as a Snap! extension block as well as the Snap! mod. The extension block would work similarly to the built-in JIT compiler block.
I know I was previously working on the TurboSnap project, which aims to achieves a similar goal. I decided to restart this because I planned for TurboSnap to only view Snap! projects, and to use a custom renderer that computes graphics effects via shaders. This project will allow you to edit Snap! projects. (And I planned all of that because apparently I was the only programmer)
I pushed an update that fixes explicit ring parameters and adds implicit parameters. Although it doesn’t throw errors that would be thrown in cases of mismatched input counts, as documented here, as I felt it was pretty unnecessary to add all those checks. (I wonder how far @bzzzz got into their project.) I also added support for custom block upvars.
I have yet to add the launch block, tell/ask, and various yielding blocks. Mainly because I felt that implementing overrides for those certain blocks wasn’t as important at this point.
As for adding continuation-passing blocks, I think I’ll run into a limitation. I believe in Snap! it copies where the current continuation is, but I can’t copy the state of a JavaScript generator. So if you run the passed continuation in the w/cc block, the script would end once the w/cc is finished, rather than restarting from after where the w/cc block was placed, which is what I believe would happen in normal Snap! Unless I’m wrong and the w/cc blocks don’t copy the current continuation. But regardless, this isn’t a major issue, since in the (although few) applications of this feature that I’ve seen, the continuation isn’t called within the block, let alone without stopping the script afterwards.
(EDIT: On second though, I think i just forgot how continuations worked, and I have nothing to worry about.)
Also, I added an example project called “3D grapher”. You can see the performance difference between JIT and non-JIT.
Just saying, for anyone wondering, a J-I-T Compiler is a Just-In-Time Compiler. Meaning that a computer will parse the program while you are coding (Statement 1) or (Statement 2) that a computer will parse the program fast for you. Either statement is true, I'm not sure which one though.
An example of a programming language with a JIT compiler is Lua. And also (fun fact) Lua is faster than Python.
Well Lua compiles to an intermediate bytecode, rather than actual machine code. So I don’t think it’d count as an actual JIT compiler. There is LuaJIT however.
Fun fact: Technically my program is an actual JIT compiler, as it compiles to JavaScript, which may then be compiled to machine code by Chrome/Chromium’s V8 engine.
Probably, but with TurboSnap, we (more like I, since I wrote all of the JavaScript code) was making it like Phosphorous in that it was built from scratch, and so reads the project XML directly, whereas this project is more like Turbowarp in that it is a mod of Snap!, and depends on Snap! to read the project XML for it. Making it a mod takes less work as I don’t have to reimplement the function of all the Snap! blocks, and the user gets to edit the project.
This doesn’t fully replace TurboSnap though. I’d like TurboSnap to have a renderer that utilizes GPU shaders. In Snap!, graphic effects are done on a single thread which is why they are slow. It could also be possible to utilize the GPU for the touching blocks for a potential speed up. That’d sound neat.
