It’s fast in terms of a response from a LLM model - but it is part of the system I am quite active on at the moment to ensure it’s performant as possible
Hi, no it doesnt, this example of course breaks using temporary registers used after the optimisation. But thats why peephole is a fallback to ir optimisation, since they are only local.
I honestly didnt think of this possibility while building the optimisation. Since constant folding is done as an ir pass i will remove the peephole pass, thanks for noticing :)
Your site is the second one I've seen using the JetBrains Mono typeface -really easy on the eyes, even when set light grey #eff1f5 on a very dark #07080d background.
Assembly requires way more work than compiling to, say C. Clang and gcc do a lot of the heavy lifting regarding optimisation, spilling values to the stack, etc
I have a couple interpreters I've been poking at and one uses 'musttail' while the other uses a trampoline to get around blowing up the C stack when dispatching the operators. As for the GC, the trampoline VM has a full-blown one (with bells-and-whistles like an arena for short lived intermediate results which get pushed/popped by the compiled instructions) while the other (a peg parser VM) just uses an arena as the 'evaluation' is short lived and the output is the only thing really needing tracking so uses reference counting to be (easily) compatible with the Python C-API. No worries about the C stack at all.
I mean, I could have used the C stack as the VM's stack but then you have to worry about blowing up the stack, not having access (without a bunch of hackery, looking at you scheme people) to the values on the stack for GC and whatnot and, I imagine, all the other things you have issues with but it's not needed at all, just make your own (or, you know, tail call) and pretend the C one doesn't exist.
And I've started on another VM which does the traditional stack thing but it's constrained (by the spec) to have a maximum stack depth so isn't too much trouble.
