> > Although it might be nice if IMC were binary at this stage (for some > > feel-good-reason?). > > You mean, that a HL like perl6 should produce a binary equivalent to > ther current .imc file? Yep - this was discussed already, albeit there > was no discussion, how this should look like. And the lexer in imcc is > pretty fast. > > > ... The current bytecode from parrot already has potential > > for slowing things down, and that's what worries me here. > > I don't see that.
My post was more a "wish-list" of what I was hoping parrot would be like in terms of imc/pbc/jit/whatever. Since I don't completely understand how parrot works, my comment above was actually more of a guess. But I'll try to explain what I meant, in the off-chance it was right. My understanding is that PBC has a limit of 16 (32?) integer registers. When a code block needs more than 16 registers, they are overflowed into a PMC. With a processor with < 16 registers, I guess this would work. Although the JIT would have to overflow more than what was originally planned in the PBC. (Or does it just switch back and forth between the VM and the JIT, I don't know.) But with a processor with > 16 registers (do such things exist?). Parrot would be overflowing registers that it could have been using in the JIT. My guess is that this would slow things down. Anyway, before I strut my ignorance of VMs and JITs and processors anymore, I think I will end this message. :) Thanks, Phil
