On Mon, Nov 04, 2002 at 10:09:06AM -0500, [EMAIL PROTECTED] wrote: > While I don't think I'm sophisticated enough to pull it off on my own, I > do think it should be possible to use what was learned to build the JIT > system to build the equivalent of a CG core on the fly, given its > structure. I think the information and basic capabilities are already > there: The JIT system knows already how to compile a sequence of ops to > machine code -- using this plus enough know-how to plop in the right JMP > instructions pretty much gets you there. A possible limitation to the
I'm not convinced. Compiling the computed goto core with any sort of optimisation turns on *really* hurts the machine. I think it's over a minute even a 733 MHz PIII, and it happily pages everything else out while it's doing it. :-( I doubt that the GC core's stats look anywhere near as impressive for the unoptimised case. [And I'm not at a machine were I can easily generate some] This makes me think that it would be hard to "just in time" > coolness, here: I think the JIT system bails out for the non-inline ops > and just calls the opfunc (please forgive if my understanding of what JIT > does and doesn't do is out of date). I think the CG core doesn't have to > take the hit of that extra indirection for non-inline ops. If so, then the > hypothetical dynamic core construction approach just described would > approach the speed of the CG core, but would fall somewhat short on > workloads that involve lots of non-inline ops (FWIW, there are more inline > ops than not in the current *.ops files). I believe that your understanding of the JIT and the GC cores are still correct. The problem would be solved if we had some nice way of getting the C compiler to generate us nice stub versions of all the non-inline ops functions, which we could then place inline. However, I suspect that part of the speed of the CG core comes from the compiler (this is always gcc?) being able to do away with the function call and function return overheads between the ops it has inlined in the GC core. I've no idea if gcc is allowed to re-order the op blocks in the CG core. If not, then we might be able to pick apart the blocks it compiles (for units for the JIT to use) by putting in custom asm statements between each, which our assembler (or machine code) parser spots and uses as delimiters (hmm. particularly if we have header and trailer asm statements that are actually just assembly language comments with marker text that gcc passes through undigested. This would let us annotate the assembler output of gcc) Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
