On Sat, Feb 08, 2003 at 05:36:58PM +0100, Leopold Toetsch wrote:
> Jason Gloudon wrote:
> >On Fri, Feb 07, 2003 at 05:49:35PM +0100, Leopold Toetsch wrote:
> >>I don't know yet, how multi threading will be done. But when multiple
> >>interpreters share the ->code data member (as newinterp/runinterp) do,
> >>then they will use the same JIT/prederef or whatever data.
> >
> >You can't do that for prederef in a multi-threaded process because prederef
> >stores the address of the registers in the interpreter structure in the
> >prederef data.
>
> Ouch, yes. So does JIT.
> So JIT/prederefed code must be separated for 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
mov (%edi,%edx),%edx
sub %eax,%edx
mov %edx,(%edi,%ecx)
jmp *(%esi)
instead of
mov 0x4(%esi),%ecx
mov 0x8(%esi),%edx
mov 0xc(%esi),%eax
add $0x10,%esi
mov (%eax),%eax
mov (%edx),%edx
sub %eax,%edx
mov %edx,(%ecx)
jmp *(%esi)
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. I believe the overhead would be quite low
with the bytecode interpreter, and negligeable with the JIT compiler.
-- Jérôme
