search for: getcontextstacktop

Displaying 7 results from an estimated 7 matches for "getcontextstacktop".

2010 Apr 11
0
[LLVMdev] Proposal: stack/context switching within a thread
...what I'd like to do, except that I don't want to be tied to a particular language and I'd like to be able to use the stack. (Also, stack use is inescapable with LLVM, as far as I can tell). 2. We should be able to support "hard switching" in Stackless Python by adding a llvm.getcontextstacktop intrinsic. If, as in Kristján's example, llvm.getcontext is used to create context A, and then execution continues until context B is created with llvm.swapcontext(B, A), the region of memory between llvm.getcontextstacktop(A) and llvm.getcontextstacktop(B) can be saved and later restored when...
2010 Apr 10
2
[LLVMdev] Proposal: stack/context switching within a thread
On the other hand, stack manipulation really ought to be handled by the target, since only the target knows the details of how the stack is laid out to begin with. Also, if we have stack manipulation calls in the IR, optimization quickly becomes very difficult. Unless we just allow optimizers to ignore the stack manipulations and assume they're doing the "right" thing. On the
2010 Apr 11
3
[LLVMdev] Proposal: stack/context switching within a thread
...ode from using pointers into another coroutine's stack, and maybe they could/should create a new context each time they need to enter a foreign frame instead of trying to copy the stack... > 2. We should be able to support "hard switching" in Stackless Python > by adding a llvm.getcontextstacktop intrinsic.  If, as in Kristján's > example, llvm.getcontext is used to create context A, and then > execution continues until context B is created with > llvm.swapcontext(B, A), the region of memory between > llvm.getcontextstacktop(A) and llvm.getcontextstacktop(B) can be saved &gt...
2010 Apr 11
0
[LLVMdev] Proposal: stack/context switching within a thread
...er which an llvm call instruction can avoid creating a new physical stack frame, but you've convinced me that it could be made to work better than I thought when I wrote that. > >> 2. We should be able to support "hard switching" in Stackless Python >> by adding a llvm.getcontextstacktop intrinsic.  If, as in Kristján's >> example, llvm.getcontext is used to create context A, and then >> execution continues until context B is created with >> llvm.swapcontext(B, A), the region of memory between >> llvm.getcontextstacktop(A) and llvm.getcontextstacktop(B)...
2010 Apr 12
4
[LLVMdev] Proposal: stack/context switching within a thread
...y area of at least size llvm.context.size() to write contexts > into, and that nothing besides the intrinsics mess with the context > structure. Yeah, that sounds right. >>> 2. We should be able to support "hard switching" in Stackless Python >>> by adding a llvm.getcontextstacktop intrinsic.  If, as in Kristján's >>> example, llvm.getcontext is used to create context A, and then >>> execution continues until context B is created with >>> llvm.swapcontext(B, A), the region of memory between >>> llvm.getcontextstacktop(A) and llvm.getcon...
2010 Apr 17
0
[LLVMdev] Proposal: stack/context switching within a thread
...pr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > I'll forward your next draft back to the stackless folks, unless you > want to pick up the thread with them. Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475 Instead of @llvm.getcontextstacktop(%context), they want @llvm.getcurrentstacktop() so that they can copy the stack out before switching, and copy it back in after switching. I'm not sure this exactly works either, since before "copying the stack back", any allocas are pointing at old-frame data and so are invalid. They...
2010 Apr 21
1
[LLVMdev] Proposal: stack/context switching within a thread
...rlap. I'm having trouble visualizing that situation. Is there a "main" context that will handle all this saving and restoring of stacks? If so, does it actually share stacks with other contexts in the way they're expected to share it with each other? > > Instead of @llvm.getcontextstacktop(%context), they want > @llvm.getcurrentstacktop() so that they can copy the stack out before > switching, and copy it back in after switching. I'm not sure this > exactly works either, since before "copying the stack back", any > allocas are pointing at old-frame data and...