At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm), I did this experiment:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor registers
This sounds pretty interesting, and I bet it could make things faster. The one thing to be careful of is that it's easy to get yourself into a position where you spend more time optimizing the code you're JITting than you win in the end.
I don't think so. Efficiency of JIT code depends very much on register save/restore instructions. imcc does a full parrot register life analysis, and knows when e.g. I17 is rewritten and thus can assign the same register for it, that some ins above I5 had. Current JIT code is looking at parrot registers and emits save/loads to get processor registers in sync, which is the opposite of:
The proposal is, to map the top N used parrot regs to physical processor registers. This means: imcc emits instructions to get parrot registers up to date and not vv. The code is already in terms of processor regs.
You also have to be very careful that you don't reorder things, since there's not enough info in the bytecode stream to know what can and can't be moved. (Which is something we need to deal with in IMCC as well)
Yep. So, I'm trying to get *all* needed info's into the bytecode stream/into the op_info/or as a hack in imcc. See e.g. "[RFC] imcc calling conventions". Please remember times where I started digging into parrot and core.ops: the in/out/inout definition of P-registers. These issues are *crucial* for a language *compiler*.
If perl6 or any other language should run *efficiently*, imcc has to be a compiler with all needed info at hand and not a plain PASM assembler.
leo
