[Vm-dev] [Cog] Fall back to interpreter. How?

[Eliot Miranda]

On Mon, Apr 23, 2012 at 4:20 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 24 April 2012 01:57, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Mon, Apr 23, 2012 at 2:28 PM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >>
> >> Hi, Eliot, all :)
> >>
> >> i skimming through the cogit, and i cannot clearly identify the code
> >> which generating code for falling back to interpreter.
> >>
> >> Say,  i want to create a native code which does nothing, just
> >> switching back to interpreter, so the bytecode of given method will be
> >> interpreted
> >> where i should look for..
> >
> >
> > The main transition from native code to machine code is on return,
> through the ceReturnToInterpreterPC, which calls ceReturnToInterpreter:,
> which does a longjmp via the reenterInterpreter jmp_buf.  But that will
> only work at return time.
> >
> > If you want to switch to the interpreter at primitive fail time things
> are going to be more complicated.  So exactly when do you want to enter the
> interpreter?  What state is the native boost call in?
> >
>
> The state is following:
>
>  - a compiled method having generated code.
>  - vm enters this code, thinking its a JITed method
>  - this code fails for some reason
>  - on a such failure, VM should switch to interpreter and interpret
> the corresponding method's body.
>
>  if native code doesn't fails, it should behave, as if method were
> performed normally (and so no need to fall back to interpreter).
>
> so, it is more or less the same how primitives behave , i.e. if method
> having a primitive, you call the prim, and if everything is ok, you
> continue running,
> if prim fails, you activating the method and interpreting its bytecode.
>

Then you should look at compilePrimitive and compileInterpreterPrimitive:.
 Basically after your NB code you want to call compileInterpreterPrimitive:
with some special entry-point that will call activateNewMethod.  In fact
you can probably just call activateNewMethod.  But what if the method is
used a lot?  Don't you want to JIT the body of the method?  I suppose its
not important.


>
> >>
> >> Also, what are hooks i need for that? Which global state should be
> changed?
> >
> >
> > The glue should modify the necessary global state, which is framePointer
> and stackPointer.
> >
> >>
> >> And finally, is there documentation about calling convention for jited
> >> code? I'd like to know what is the state of registers when VM enters
> >> the jited method, and what their purpose.
> >
> >
> > See
> StackToRegisterMappingCogit>>callingConvention, StackToRegisterMappingCogit>>numRegArgs and
> CogIA32Compiler>concreteRegister:.  With the  SimpleStackBasedCogit
> everything is passed on the stack.  With StackToRegisterMappingCogit, with
> <= 1 arg, args are passed in ReceiverResultReg and Arg0Reg (but with the
> new object represnetation I will up the number of register arguments to 2).
>  But to protect the CoInterpreter from these details the registers are only
> visible to primitives.  Primitive failure or prolog code pushes them onto
> the stack.  See StackToRegisterMappingCogit>>genPushRegisterArgsForNumArgs:
> and senders, especially StackToRegisterMappingCogit>>genPushRegisterArgs,
> which is called from three places, one for method frame build, one for
> primitive failure and one for closure activation.
> >
> > In addition, on calling a method's checked entry-point (see
> Cogit>compileEntry) ClassReg holds the class when the send site was linked,
> and ClassReg holds the message selector when the send is unlinked (which
> will through glue call CoInterpreter>>ceSend:super:to:numArgs:.
> >
> > HTH
> >
> > and if this is still confusing we could try skyping tomorrow.
>
> ah.. i am not focused on this task.. right now i collecting necessary
> bits of information. But thanks for the offer and info. I will, of
> course, bother you more when i will start making it for real :)
>
> > --
> > Eliot
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120423/3fdf7888/attachment-0001.htm