<br><br><div class="gmail_quote">On Mon, Aug 16, 2010 at 1:05 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;">
<div class="im"><br>
On 16 August 2010 21:26, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
> Hi Igor,<br>
><br>
> On Mon, Aug 16, 2010 at 9:42 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> i want to adopt an image-side scheduling for Cog and since<br>
>> everything which sounds like 'Process' will be wiped out from VM,<br>
>> i need a way to cleanly switch the active context to a new one.<br>
>><br>
>> I think that as a guide for implementation could be taken<br>
>> CoInterpreter>>transferTo: newProc from: sourceCode<br>
>><br>
>> but i am a bit confused by following:<br>
>><br>
>> self push: instructionPointer.<br>
>> ...(switching code)...<br>
>> instructionPointer := self popStack.<br>
>><br>
>><br>
>> does that means, that instruction pointer is always stored in last<br>
>> stack position<br>
>> instead of some fixed slot of context?<br>
><br>
> You need to internalize <a href="http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/" target="_blank">http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/</a>. Cog /does not/ use contexts for managing execution. It uses stack frames, and in an inactive stack frame on top of stack the instructionPointer is at top of stack (*). So I suggest you read the above blog entry at least three times until it all starts to make sense. Then you'll have to understand how the CoInterpreter complicates things by having two kinds of frame, one for interpreted methods and one for JIT-ed native methods, see CoInterpreter class>>initializeFrameIndices, and understand that an interpreter frame needs two instruction pointers, the normal one which is a return address for native code that jumps into the interpreter (see ceReturnToInterpreter:), and the one in the interpreted frame's iframeSavedIP slot which holds the bytecode pc (at which the interpreter should start executing).<br>
><br>
<br>
</div>I am actually need few things to understand: how much state should be<br>
preserved/swapped and in what order.<br>
I seen you post and even tried to read it befor, but reading it<br>
without using in practice is almost waste of time, because<br>
i best work using trial & fail process, instead of reading books and<br>
following rules :) That's how my mindset works,<br>
and that's why i liked smalltalk so much, when i first seen it,<br>
because it makes trial & fail process extremely easy and<br>
enjoyful.<br></blockquote><div><br></div><div><blush>me too</blush></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
But thanks for reminder, i'll use your blog post as a reference :)<br>
<div class="im"><br>
> (*) of course Cog does use contexts, but they are used as little as possible. When you say "thisCOntext" a context gets created for a frame, and when teh stack zone fills up, stack pages are freed by copying all frames on a page to the heap as contexts, and when a snapshot is created all stack pages are freed, converting all frames to contexts. So from the image this optimization is completely invisible, apparently all method activations are contexts, but the VM creates context objects only when necessary or convenient, and certainly /not/ on every send.<br>
<br>
</div>Yes, i am aware that contexts is used as less as possible. But from<br>
language perspective, a context is still a smallest possible<br>
unit of computation, which you can safely operate with. So, it is<br>
logical to have a primitive which switching an active context,<br>
instead of active process(es).<br>
Also, same thing is userful for callbacks, by taking a simple block<br>
closure, which should handle callback<br>
and turning it into context, which then can be activated, once<br>
callback is called.<br></blockquote><div><br></div><div>Right, so you implement that primitive, but in Cog it must be implemented like transferTo:from:. i.e. in the frame you're leaving you must push the instruction pointer and ensure the frame has a context (since the context will persist, not necessarily the frame). The context you're transferring to needs to have a frame before one can continue, so the primitive uses makeBaseFrameFor: if the context is not already married to a frame.</div>
<div><br></div><div>cheers,</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> HTH,<br>
> Eliot<br>
>><br>
>> --<br>
>> Best regards,<br>
>> Igor Stasenko AKA sig.<br>
><br>
><br>
><br>
<br>
<br>
<br>
</div>--<br>
<div><div></div><div class="h5">Best regards,<br>
Igor Stasenko AKA sig.<br>
</div></div></blockquote></div><br>