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

[Eliot Miranda]

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

>
> On 24 April 2012 02:42, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > 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.
>
> thanks. this looks fairly simple :)
>
> >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.
> >
>
> apparently i don't want to jit the body, because then i will have to
> maintain
> own native code + jited code in addition, and VM has only one way to
> identify and use CompiledMethod(s) with jited code..
> because the idea is to make cogit think that the code NB generated at
> language side is the code he jited itself :)
>
> since there is 99.9% expectation that normally primitive won't fail,
> it is not important to optimize/jit method body anyways,
> because it usually contain a lot of error checking and fallback code
> and native code generation.. and it don't needs to be blazingly fast .
>

Then you need something like

"Save processor fp, sp and return pc in the interpreter's frame stack and
instruction pointers"
self genExternalizePointersForPrimitiveCall.
"Switch to the C stack."
self genLoadCStackPointersForPrimCall.
"Call activateNewMethod."
  self CallRT: #activateNewMethod asSymbol asInteger.

(the asSymbol is important for Slang)

The only issue here is that if a callback from NB can occur then the other
state (newMethod argumentCount) either needs to be saved/restored around
the callback or saved/restored around the NB callout.


> >>
> >>
> >> >>
> >> >> 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
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>



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