Hello! > Interesting. Dealing with end-of-buffers situation is indeed tricky > with lightning, and register allocation is lacking (I thought this > wouldn’t necessarily be a problem because we can do a reasonable job > with a fixed set of statically allocated registers.)
That seems true, yes. Given that most of the instructions won't need to be translated, it's possible that switching back over in the middle of the project wouldn't be that hard. (I have a partially-completed Lightning JIT to start from, too.) > I think it’s OK to jit just at call time at first. There could be a > call counter on procedures, which would allow you to determine whether > it’s worth jitting (i.e., only jit a procedure after it’s been call at > least N times.) That sounds good. I think it should probably be activated by all of the 'call' instructions, with a counter on procedures. There is also something that I was trying to figure out but couldn't - how does code from the REPL make its way into the VM? Specifically, what entry point should I modify if I want REPL code to be JITted automatically? (Is it one of the call instructions other than 'mv-call', or a call to a 'vm-*-engine' function?) That would make testing this a lot easier. > My plan was to use macro magic to turn each ‘VM_DEFINE_INSTRUCTION’ into > a function definition, except for the ‘call’ instructions and similar. > Then all the jit’d code would do is call these functions, so jitting > would be quite simple. Still, it’d remove one layer of interpretation, > which could lead to performance gains. > > Then instructions could gradually be rewritten in libjit assembly, but > that takes time. That makes sense. I have an alternate idea about how to do this, but please bear with me, because it would be a little strange. I could certainly rewrite the important instructions with libjit, however, this would result in duplicated code, which is not ideal. I was wondering if you would be interested in coming up with a way to write them once so that they could be expanded to either directly-runnable C code or libjit calls. (Libjit basically implements a subset of C, so I don't think this would be too difficult.) I was also wondering (and here's where the build process would get weird) if this language could be translated with Guile. The goal would be to wind up with a situation where Guile has the ability to take some description of low-level machine operations and translate them either into regular C code or into libjit calls. The reason is that it would be a small step from there to building a libjit-based assembler directly into Guile, and then you've got the ability to compile things into machine code using only Scheme. (You could, for instance, then write a custom compiler for regular expressions that didn't go through the regular Guile VM instructions but just jumped to machine code. That might be really, really fast. You could also then start writing optimizations of Guile code in Guile.) The trouble would be that then Guile would be used to build Guile. It would still be possible to have a version which was completely C code, but that wouldn't be the source version. I know this would be moving in a strange direction, and I would understand if you thought this was a bad idea, but I think it would have have interesting benefits. > I’m looking forward to the next news bulletin. ;-) Thanks! I'll work on that. :-) Noah
