The goal is just to be faster, hopefully significantly faster. There are definitely a lot of smaller and/or older devices that would benefit. And I’d draw a comparison with Javascript—that was “fast enough” 5 years ago, but when V8 initiated the Javascript Wars, that enabled a bunch of cool new applications.
As to the approach I outlined, I like the idea of doing something that could address a few different needs at once, even if some of them are a bit speculative (especially the iOS native app).
Wrap it twice and maybe it’ll get even faster!
I’m definitely not comfortable in plain JS, so I’ll leave that to you! (I tried to contribute a bit to Quixe, but I don’t think I actually saved zarf much time.)
Git gets pretty good leverage out of a cheap-ass version of the same idea—it doesn’t build a syntax tree, it just remembers a label for each Glulx opcode. Then for branches with immediate offsets, it just emits a “goto” into the gitcode. For function calls, it could emit a direct jump to any function that’s already compiled (which will be many of them, if you recursively compile any newly-encountered functions); can’t remember if I got around to doing that.
Building a syntax tree definitely enables a bunch of other optimizations, like transforming the stack into local variables. Though opcodes like “stkroll” get in the way of that, and I don’t know how common they are. That’s why I was initially thinking of LLVM or Java; just directly translate Glulx into stack-based code and let their clever optimizers figure it out.
I’ve been trying to think if there’s useful overlap between what we’re working on. Maybe benchmarks and test harnesses—I was a bit slapdash with that for the original Git, and this time round I’d like to have a a good suite of test programs. And it might be useful to have something I’m going to call “Traceglk”, which can capture and replay a program’s entire Glk interaction, rather than just using Cheapglk.
Yep. I think I’ll save the whole-game-precompilation idea as a backup plan. I think there is value in sweating that 2% and handling every case, just as JS interpreters today have to allow for all sorts of crazy edge cases, because JS is crazy. I still feel a little bad for punting on 1- and 2-byte locals in Git; they weren’t impossible to support, just really tedious. (On the other hand, I’m so glad you deprecated those!)