Guile is a really interesting story in that they've spent ages doing some fantastic optimisations, of the kind you usually don't do when your final execution engine is just an interpreter. I used to read Andy's blog posts about compilers unaware that the pipeline didn't actually end in machine code. Hopefully that makes the template JIT they have here enough to get good performance as the input should already be in really good shape.
I wonder why Andy didn't chose to write the JIT in Guile itself, with a binding to Lightening, rather than in C. Guile is designed to be embedded and have bindings written for it.
What I love about the guile optimizer (and some lisp optimizers in general) is that you usually have a first step of source to source optimization. That means I can write some code and see what gets inined, hoisted, unrolled and removed without having to read the bytecode assembly.
That is especially nice when writing complex macros. I remember writing a loop utility and realized I couldn't run the optimizer on code where everything was known at compile time, since guile usually optimized the loop away. (for/sum ((i (in-range 5)) i) expanded into 20 lines of code, but optimized to the integer 15 :)
The tricky think about a source-to-source transformation, is where do you store the meta-data to map the new source back to the old source, for the purposes of error reporting, debugging, and deoptimisation? You can't just map from one list to another as your optimisation function.
> I wonder why Andy didn't chose to write the JIT in Guile itself, with a binding to Lightening, rather than in C. Guile is designed to be embedded and have bindings written for it.
OP states "eventually I should be migrating this code over to Scheme anyway. And, of course, simple can mean fast, and I needed fast code generation.". That does not anwer you actual question (and neither does the article), but I gather this was to make the project finite (solve one and only one problem only at a time), not because the author was not aware.
Yes that’s the statement I’m responding to “I didn't want to add more complexity to the C side of Guile“ but this is more C code. Maybe speed of generation was more important than anything else then.
I wonder why Andy didn't chose to write the JIT in Guile itself, with a binding to Lightening, rather than in C. Guile is designed to be embedded and have bindings written for it.