<br><br><div class="gmail_quote">On Mon, Apr 23, 2012 at 2:28 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi, Eliot, all :)<br>
<br>
i skimming through the cogit, and i cannot clearly identify the code<br>
which generating code for falling back to interpreter.<br>
<br>
Say, i want to create a native code which does nothing, just<br>
switching back to interpreter, so the bytecode of given method will be<br>
interpreted<br>
where i should look for..<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, what are hooks i need for that? Which global state should be changed?<br></blockquote><div><br></div>
<div>The glue should modify the necessary global state, which is framePointer and stackPointer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And finally, is there documentation about calling convention for jited<br>
code? I'd like to know what is the state of registers when VM enters<br>
the jited method, and what their purpose.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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:.</div>
<div></div></div><div><br></div>HTH<div><br></div><div>and if this is still confusing we could try skyping tomorrow.<br>-- <br><div>Eliot</div><br>
</div>