search for: stackless

I took the liberty of forwarding this to the Stackless Python list, since they switch stacks, and I got a response at http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4467. The upshot is that they really need the ability to allocate only a tiny amount of space for each thread and grow that as the thread actually uses more stack. The way t...

Hi, I am using XEN-4.1.2 and linux-2.6.32 as dom0. After I upgraded stackless python from 2.5 to 2.7 (and rebuilt xen). XenAPI became unusable, I spent some time to investigate XenAPI,py, it looks fine. So, I guess xend has problem with python 2.7, because it always returned method unknown. Do I have to tweak xend to let it support python 2.7? Thanks, Eric /root # python...

...is that context creators be given > a memory 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...

...n Sanduleac<sanduleac.dan at gmail.com> >> wrote: >> > Hi, >> > >> > I'm trying to compare different Python-C wrapping techniques to see >> > which >> > would be faster and also more suited to game development. >> > I'm using Stackless Python 2.6.2 at 74550 / GCC 4.3.3, and boost 1.39.0 on >> > Ubuntu 9.04. I implemented a simple Vec3 (3D vector) class in C++ and >> > wrapped it with boost::python. All it does is multiplications and >> > additions, >> > so it implements just two operators for p...

...orial, on the topic of closures, > mentions that there are "often better ways to implement these features > than explicit stack frames". Does anyone know what techniques this > cryptic statement might be referring to? > > Thanks! > I would say it means to have a "stackless" code generator. You may want to see http://en.wikipedia.org/wiki/Spaghetti_stack and http://www.nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt . "Stackless" means that you do not use the "system" stack, but that rather, your language frontend manages the stac...

Hi all, At the bottom of chapter 8 of the tutorial, on the topic of closures, mentions that there are "often better ways to implement these features than explicit stack frames". Does anyone know what techniques this cryptic statement might be referring to? Thanks! -- William <wmorgan-llvm at masanjin.net>

Right now the functionality is available, sometimes, from the C standard library. But embedded environments (often running a limited standard library) and server environments would benefit heavily from a standard way to specify context switches within a single thread in the style of makecontext/swapcontext/setcontext, and built-in support for these operations would also open the way for

On Sat, Apr 10, 2010 at 12:54 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > I took the liberty of forwarding this to the Stackless Python list, > since they switch stacks, and I got a response at > http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4467. > The upshot is that they really need the ability to allocate only a > tiny amount of space for each thread and grow that as the thread > actually u...

..., which you can answer here or there: > Point 4 is a bit confusing. Normally, it's fine for a thread to share > some of its stack space with another thread, but your wording seems to > prohibit that. Really? How does that work? > > I'll forward your next draft back to the stackless folks, unless you > want to pick up the thread with them. If you're willing to be the go-between, I really appreciate it.. I don't think I have the time to really get involved with Stackless Python, especially as I would have to learn regular Python first.

...interpretation from compiled code) >> >> Hello, >> >> What's your plan for restoring register and memory state? > > Put everything in memory at the yield point, > (its for x86 only at the moment). > Not super efficient, but should work. Is your interpreter stackless? If it's stackless, you can put your entrypoint at the beginning of a Function, and then just call it. LLVM doesn't support taking the real address of a label. It may some day, but that won't by itself make it safe to jump into compiled code from separately-compiled code. To do that, y...

Having read through Stackless Python's web pages a bit: 1. They're doing pretty much 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...

On Sun, Apr 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...

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

On Fri, Apr 16, 2010 at 9:30 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Sun, Apr 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 (From the reply) > But any function call we perform after the > swapcontext() may trample the unsaved stack, if the source and destinati...

Dan, > > On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote: > >> Hi, >> >> I need to get the address of a label in jitted code. >> (This is so that I can insert a jump into the machine code to resume >> interpretation from compiled code) > > Hello, > > What's your plan for restoring register and memory state? Put everything in memory at

...an generate code in continuation-passing style or do all of its user-level "stack" frame manipulation on the heap. Then it only uses a constant amount of C-stack space, which might not be part of the context that needs to be switched. Only foreign calls necessarily use a chunk of C stack. Stackless's approach does seem to prevent one coroutine's foreign code 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 &qu...

...iled code) >>> Hello, >>> >>> What's your plan for restoring register and memory state? >> Put everything in memory at the yield point, >> (its for x86 only at the moment). >> Not super efficient, but should work. > > > Is your interpreter stackless? If it's stackless, you can put > your entrypoint at the beginning of a Function, and then just > call it. No it has a stack, but I can guarantee that the ENTIRE state of the VM is recoverable. (I force all variables into memory at the yield point). And I need to insert the jump at runt...

...of the Gothenburg sprint is to start exploring new directions and continue in the directions started at the Paris sprint. The currently scheduled main topics are: - The L3 interpreter, a small fast interpreter for "assembler-level" flow graphs. This is heading towards JIT work. - Stackless: write an app-level interface, which might be either Tasklets, as in "Stackless CPython", or the more limited Greenlets. - Porting C modules from CPython. (_socket is not finished) - Optimization/debugging work in general. In particular our thread support is far from stable at...

...continuation-passing style or do > all of its user-level "stack" frame manipulation on the heap. Then it > only uses a constant amount of C-stack space, which might not be part > of the context that needs to be switched. Only foreign calls > necessarily use a chunk of C stack. Stackless's approach does seem to > prevent one coroutine's foreign code 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... I see what you mean....

...end(work_on(shared_var)); } is legal with posix threads. It's just illegal to return out of a function while its stack space is used by another thread. I've seen this used inside a condition variable implementation, among other places. >> I'll forward your next draft back to the stackless folks, unless you >> want to pick up the thread with them. > > If you're willing to be the go-between, I really appreciate it..  I > don't think I have the time to really get involved with Stackless > Python, especially as I would have to learn regular Python first. Sure.