Jerome Vouillon wrote: [ prederef/JIT and threads ]
I'm not sure this is the right think to do. If we force gcc to store
in a machine register the address of the Parrot registers, it should
generate some code which is just as fast as the prederefed one. For
instance, the sub opcode would be
; %esi contains the code pointer
; %edi contains the address of the current thread registers
mov 0x4(%esi),%ecx
mov 0x8(%esi),%edx
mov 0xc(%esi),%eax
add $0x10,%esi
mov (%edi,%eax),%eax ; base %edi + offset of the register %eax
Yep. And for better locality of interpreter->ctx parrot interpreters should be allocated from a separate mem pool, where all interpreters are side by side.
We still have a problem with all these opcodes with constants. I
think we should drop them. We can just keep some of the "set" opcodes
to load a constant into a register, and then all other opcodes would
work only with registers.
Yes. And worse, we have e.g. add_i_ic_ic and such. I think a smaller core would be faster anyway.
-- Jérôme
leo
